| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 13:55:00 | diga | okay | |
| 13:55:04 | edleafe | diga: in #openstack-meeting-alt | |
| 13:55:21 | diga | edleafe: Sure, will join | |
| 13:56:07 | andreykurilin | amrith: hi | |
| 13:56:23 | amrith | hi andreykurilin | |
| 13:56:33 | amrith | did you see the email I just sent you | |
| 13:56:47 | andreykurilin | yes | |
| 13:56:50 | johnthetubaguy | bauzas: you say only ironic needs the host field, isn't that what we use for the RPC call? | |
| 13:57:05 | amrith | the issue I'm facing is that if I use the v6.0.0 client things work fine | |
| 13:57:15 | amrith | if I switch to the v7.0.0 client, it bombs out | |
| 13:57:21 | bauzas | johnthetubaguy: I meant the problem is that host != node for Ironic | |
| 13:57:23 | johnthetubaguy | bauzas: or is that the node vs host thing | |
| 13:57:29 | bauzas | yup that | |
| 13:57:29 | amrith | am not sure why that would be the case | |
| 13:57:30 | johnthetubaguy | bauzas: ah, gotcha | |
| 13:57:36 | bauzas | maybe my comment is unclear, sorry if so | |
| 13:57:38 | andreykurilin | amrith: I have just several minutes before meeting and will able to help you in ~30 minutes | |
| 13:57:48 | bauzas | but I can't say that I could just use the RP name | |
| 13:58:01 | bauzas | given it's the nodename which can be different for ironic | |
| 13:58:05 | amrith | andreykurilin, I'll be here. | |
| 13:58:13 | andreykurilin | amrith: but now I have one question: What is user.tenant https://github.com/openstack/trove/blob/master/trove/tests/util/__init__.py#L170 here? Is it tenant name or id? | |
| 13:58:23 | bauzas | while the other drivers (except the Fake driver, but that's fixed in a bottom patch) are using host == node | |
| 13:58:29 | bauzas | johnthetubaguy: ^ | |
| 13:58:31 | amrith | looking | |
| 13:59:56 | johnthetubaguy | bauzas: the custom resource class stuff should fix that, I am assuming | |
| 14:00:13 | bauzas | johnthetubaguy: yeah, but it could be merged by Pike | |
| 14:00:23 | bauzas | johnthetubaguy: hence me using the new object method I created | |
| 14:00:44 | bauzas | we could just cut that once the above BP you mentioned is fully merged | |
| 14:01:00 | bauzas | but AFAICS, that's still not done yet hence my big fat comment | |
| 14:01:14 | johnthetubaguy | bauzas: yeah, no biggie, just getting my head straight on that | |
| 14:01:40 | bauzas | np | |
| 14:01:55 | bauzas | johnthetubaguy: I have a bigger concern that I wrote in a ML thread this week-end | |
| 14:02:03 | edleafe | bauzas: scheduler meeting? | |
| 14:02:11 | bauzas | edleafe: I can do, for 20 mins | |
| 14:02:21 | edleafe | cool | |
| 14:02:23 | amrith | andreykurilin, one second, you are looking at the tests. I wasn't running test code | |
| 14:02:32 | bauzas | edleafe: but I'm pretty down given all the work I'm doing atm | |
| 14:02:33 | andreykurilin | ok... | |
| 14:02:34 | amrith | I was running a straight trove command which tried to hit nova | |
| 14:02:42 | amrith | I will find out what that is | |
| 14:02:58 | andreykurilin | I just look at first failure at gates:) | |
| 14:03:01 | andreykurilin | *looked | |
| 14:03:12 | amrith | but for what I've been trying to do, the code is at https://github.com/openstack/trove/blob/master/trove/common/remote.py#L101 | |
| 14:03:17 | amrith | ah, sorry | |
| 14:03:27 | amrith | I am running trove locally to debug | |
| 14:03:38 | amrith | here, we're making a client with version 2.12 | |
| 14:03:58 | amrith | which comes from https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L67 | |
| 14:04:05 | amrith | and we're passing in a bunch of parameters | |
| 14:04:23 | amrith | my specific issue (and like I said in the email, trove may be doing something wrong here) | |
| 14:04:33 | amrith | we're making the call like https://github.com/openstack/trove/blob/master/trove/common/remote.py#L101 | |
| 14:04:49 | amrith | and if I understand compatibility right, this should work unchanged with the v7.0.0 client from nova | |
| 14:04:51 | andreykurilin | amrith: need to go to meeting, sorry. PS: it should help(with depends-on) ttps://review.openstack.org/412497 | |
| 14:04:51 | amrith | but it isn't | |
| 14:05:09 | amrith | nope, doesn't help | |
| 14:05:15 | amrith | tried it | |
| 14:05:36 | amrith | something else is broken, not sure where | |
| 14:05:51 | amrith | the issue I'm facing is that nova returns a 403 (forbidden) on a simple thing like flavor list | |
| 14:05:54 | andreykurilin | amrith: I added depends-on there | |
| 14:06:17 | bhagyashris | cdent: Ok. Thank you. :) | |
| 14:06:21 | andreykurilin | amrith: did you check it with pulling not-merged changed from novcliane? | |
| 14:06:25 | amrith | oh, sorry | |
| 14:06:27 | amrith | different change | |
| 14:06:30 | amrith | let me look | |
| 14:06:43 | amrith | NO, I did not check with pulling not merged change in novaclient | |
| 14:06:48 | amrith | that may be it. let me check | |
| 14:06:53 | amrith | catch yo after your meeting | |
| 14:06:54 | amrith | thanks! | |
| 14:07:34 | alex_xu | johnthetubaguy: sdague, hope you can take a look at this patch https://review.openstack.org/#/c/423952/5, we break some old microversion in newton release. cdent have a good point on it. I'm not sure we can fix it directly, maybe another microversion? | |
| 14:08:20 | johnthetubaguy | alex_xu: yeah, sounds like it should be added back in a the next microversion | |
| 14:10:04 | alex_xu | johnthetubaguy: yea, we already bump few versions after break that. | |
| 14:14:13 | sdague | alex_xu: so, before fixing it, is there something we can learn about how to not let something like that fall through review again? | |
| 14:15:05 | sdague | no one seemed to catch that over a lot of review iterations (64 revisions on that patch, that bug showed up in revision 44) | |
| 14:15:13 | sdague | https://review.openstack.org/#/c/304510/44/nova/api/openstack/compute/block_device_mapping.py | |
| 14:15:43 | diana_clarke | amrith, andreykurilin: Horizon is reporting a similar issue with python-novaclient 7.0.0. https://bugs.launchpad.net/python-novaclient/+bug/1658148 | |
| 14:15:43 | openstack | Launchpad bug 1658148 in OpenStack Dashboard (Horizon) "Horizon/Nova interactions broken " [Critical,New] - Assigned to Rob Cresswell (robcresswell) | |
| 14:16:04 | alex_xu | sdague: i'm thinking is there any test can cover that. we probably only run the test on specific version, not in the future version. | |
| 14:17:28 | alex_xu | but even the test can run in the future version, but the bug only can be found when we bump a new version | |
| 14:18:56 | sdague | alex_xu: right, I was wonder if we could iterate through the schema and compare at various versions | |
| 14:19:13 | sdague | including a fake new version after the one being committed | |
| 14:19:23 | sdague | and if we see a blip and back, that's probably wrong | |
| 14:19:24 | andreykurilin | amrith: ok, I returned | |
| 14:19:51 | bauzas | jaypipes: I thought you were on PTO | |
| 14:19:59 | alex_xu | sdague: yea, that should works | |
| 14:20:46 | alex_xu | sdague: actually that patch fixes two bugs, another one break the old microversion in the later patch. | |
| 14:21:59 | alex_xu | maybe we should run the api sample tests on the specific version and the lastest version. it is fine to find bug before we bump next version | |
| 14:22:36 | sdague | alex_xu: yeh | |
| 14:22:49 | sdague | that might be good enough as well, run everything at n+1 | |
| 14:23:05 | sdague | I don't know, just trying to figure out how to make it easier for folks | |
| 14:23:33 | sdague | honestly, == is probably always the wrong answer for microversion comparison | |
| 14:24:01 | alex_xu | yes, that is totally wrong. | |
| 14:26:21 | sdague | if version stops being a string, and is actually a version object when it gets to get_server_create_version then it would be harder to make it an equality | |
| 14:26:59 | sdague | version.between('2.32', None) | |
| 14:27:37 | sdague | if you really want an equal, then do between('2.32','2.32') | |
| 14:27:47 | sdague | that will be a lot more obvious to reviewers that it is wrong | |
| 14:28:14 | sdague | that might be more effective than complicated testing | |
| 14:34:20 | amrith | hi andreykurilin | |
| 14:34:37 | amrith | let's watch the change you proposed (with the dependency) | |
| 14:34:39 | amrith | and go from there | |
| 14:34:44 | amrith | I'm looking at the test you mentioned | |
| 14:34:46 | amrith | which also failed | |