| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 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 | amrith | but it isn't | |
| 14:04:51 | andreykurilin | amrith: need to go to meeting, sorry. PS: it should help(with depends-on) ttps://review.openstack.org/412497 | |
| 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 | openstack | Launchpad bug 1658148 in OpenStack Dashboard (Horizon) "Horizon/Nova interactions broken " [Critical,New] - Assigned to Rob Cresswell (robcresswell) | |
| 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: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 | |
| 14:34:51 | amrith | last time around | |
| 14:35:31 | andreykurilin | amrith: actually, it looks like I have a workaround (depends-on patch looks like not ready yet and require some additional work). I'll propose one more change | |
| 14:35:44 | amrith | ok, thx andreykurilin | |
| 14:36:55 | alex_xu | sdague: yea, we can pass the object instead of string. but the object support __eq__ :) | |
| 14:40:19 | alex_xu | johnthetubaguy: sdague, so that bug need to be fixed by microversion, is that something we can done before release, or it will be a Pike thing. And have a reno 'issue' note in Ocata? | |
| 14:41:06 | sdague | alex_xu: I think we should make the object stop supporting eq natively | |
| 14:42:03 | johnthetubaguy | I am with sdague on stopping the route cause here urgently | |
| 14:42:44 | sdague | alex_xu: so, what happens when 2.33 is used? | |
| 14:42:44 | alex_xu | sdague johnthetubaguy : ok, I will check that tomorrow | |
| 14:43:29 | andreykurilin | amrith: what is context.token here https://github.com/openstack/trove/blob/master/trove/common/remote.py#L102 ?) | |
| 14:45:29 | alex_xu | sdague: emm...looks like there is no 'addtionalProperties: False', that means the tag still work in the 2.33, just lose validation, I need to check that | |
| 14:45:48 | jroll | edleafe: one more question, did we figure out what an ironic flavor using resource classes looks like yet? | |
| 14:45:53 | jroll | jaypipes: ^^ | |
| 14:45:56 | sdague | alex_xu: it would be extremely useful to me to get a mailing list post out about what went wrong, what this allows, and what the fall out from various fixing options would be | |
| 14:46:29 | sdague | because otherwise everyone needs to build that up in their own head from scratch, and it's hard to agree on path forward unless we all agree where we stand | |
| 14:46:51 | edleafe | jroll: good question | |
| 14:47:05 | alex_xu | sdague: i see now. I will investigate more, then send out an email | |
| 14:47:09 | jroll | edleafe: I'd like to have that in my docs for the ironic install guide, I guess | |
| 14:47:20 | edleafe | jroll: I'm still not clear on whether we need to add the resource class to the flavor | |
| 14:47:20 | jroll | though, if it doesn't work until pike, idk | |
| 14:47:37 | jroll | edleafe: how else do we map a flavor to said resource class? | |