| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 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? | |
| 14:47:52 | edleafe | jroll: or if there is some other mapping | |
| 14:47:56 | sdague | alex_xu: thank you | |
| 14:47:57 | edleafe | jroll: jinx | |
| 14:48:02 | alex_xu | sdague: np | |
| 14:48:48 | edleafe | jroll: my understanding is that the flavor will be: CUSTOM_IRONIC_CLASS: 1 | |
| 14:49:13 | edleafe | jroll: and that placement will find a provider for that class | |
| 14:49:15 | jroll | edleafe: where, in the flavor? e.g. how do I create said flavor? | |
| 14:49:33 | edleafe | jroll: IOW, no disk/ram/cpu BS like now | |
| 14:50:13 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489 | |
| 14:50:14 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997 | |
| 14:50:15 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744 | |
| 14:50:21 | edleafe | jroll: well, like any other flavor, but not sure what changes the custom RC stuff will need | |
| 14:50:41 | jroll | edleafe: sure, so just nova flavor-key my-flavor set CUSTOM_FOO_THING=1? | |
| 14:50:43 | jroll | right | |
| 14:50:47 | edleafe | jroll: jaypipes had all this on his mental whiteboard | |
| 14:51:17 | jroll | edleafe: so here's the thing, if we require this to be set up for a smooth upgrade to pike, then we need to be able to make a working flavor in ocata | |
| 14:51:34 | edleafe | jroll: agreed | |
| 14:51:54 | jroll | edleafe: and we're three days from feature freeze and this is but a butterfly in jaypipes' brain, correct? | |
| 14:52:20 | edleafe | jroll: unless that butterfly laid some eggs in cdent's brain, yet | |
| 14:52:25 | edleafe | s/yet/yes | |
| 14:52:52 | edleafe | jroll: He may have written it up somewhere - I can dig for it | |
| 14:52:55 | jroll | edleafe: I mean, if it isn't written down at this point, I don't believe it will happen, which means this can't be mandatory fora pike upgrade | |
| 14:52:56 | jroll | okm, | |
| 14:52:58 | jroll | ok* | |
| 14:53:06 | jroll | thanks | |
| 14:53:15 | jroll | all I've seen is maybe an extra spec | |
| 14:53:18 | edleafe | jroll: I'll let you know what I find | |
| 14:53:25 | jroll | edleafe: thank you | |
| 14:56:40 | sfinucan | vladikr: Comments left on https://review.openstack.org/#/c/421186/2 | |
| 14:58:17 | vladikr | sfinucan, thanks | |
| 15:00:12 | amrith | andreykurilin, the token there is something that the client (trove client) would have created and passed to the server. so the auth and token creation is done on the trove client side and the API service (or TM) on the trove control plane uses those credentials. That would be a keystone token. | |
| 15:01:08 | andreykurilin | amrith: oh, sorry. I wrote the wrong question :( it should be : what is tenant there | |
| 15:01:33 | amrith | project_id | |