| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-15 | |||
| 18:08:26 | dansmith | oh | |
| 18:08:29 | edleafe | But yeah, I was planning on completing it | |
| 18:08:36 | edleafe | until this morning | |
| 18:08:54 | dansmith | okay.. no update since may 11 | |
| 18:09:08 | dansmith | I guess we're expecting something presently? | |
| 18:09:23 | edleafe | I'm curious, though - where do you see the claim fail logic missing? | |
| 18:10:29 | dansmith | if we fail doing _allocate_for_instance() here, we need to retry the claim for the same instance, but on the next host right? https://review.openstack.org/#/c/460455/6/nova/conductor/manager.py | |
| 18:10:45 | dansmith | L957 just moves on to the next instance, right? | |
| 18:10:46 | edleafe | dansmith: fwiw, I was on PTO May 12, and came back in town this morning to a big fat -2 | |
| 18:11:21 | dansmith | edleafe: I meant no update on bauzas' conductor claim one | |
| 18:11:29 | dansmith | edleafe: yours have been updated more recently, AFAICT | |
| 18:11:31 | edleafe | dansmith: oh, you mean bauzas' series. I thought you meant mine | |
| 18:11:39 | dansmith | nope | |
| 18:11:43 | edleafe | ah | |
| 18:11:49 | dansmith | so actually, | |
| 18:12:00 | dansmith | if we fail to claim on L957 do we just stop building everything? | |
| 18:12:04 | dansmith | I'm kinda assuming we do | |
| 18:12:04 | edleafe | bauzas did mention that he was ready with a new PS real soon | |
| 18:12:28 | dansmith | actually, maybe we don't explode, but just continue with no allocation? | |
| 18:12:29 | dansmith | eesh | |
| 18:12:48 | edleafe | ...which negates the whole point of eliminating the race, no? | |
| 18:13:23 | dansmith | well, it's just completely wrong | |
| 18:13:34 | dansmith | we can't ask compute to build an instance we didn't actually claim for :P | |
| 18:13:49 | edleafe | My series didn't (yet) account for the computes not all being updated to the latest | |
| 18:14:00 | edleafe | was hoping for guidance on that | |
| 18:14:42 | dansmith | yeah, so what bauzas has there is how to do that | |
| 18:14:47 | dansmith | checking the service version | |
| 18:15:15 | dansmith | I feel like we also probably want to communicate to the compute that it should expect the allocation to have been done already | |
| 18:15:15 | edleafe | well, yeah, but I didn't think it was right for the scheduler to know about such things | |
| 18:15:43 | dansmith | well, I dunno.. scheduler knows such things in a couple places I think, but it's definitely okay for conductor to know that | |
| 18:15:45 | mriedem | dansmith: we agreed a few weeks ago that the compute would look for existing allocations and if none found, assume the control layer didn't do that | |
| 18:15:46 | edleafe | the compute checks already, if I'm not mistaken | |
| 18:15:51 | edleafe | in bauzas' series | |
| 18:16:04 | edleafe | mriedem: bingo | |
| 18:16:10 | dansmith | mriedem: okay, well, we better be damn sure that we fix the bug here :) | |
| 18:16:28 | dansmith | because this code will not claim and just send it to the compute, destined for certain failure | |
| 18:17:07 | dansmith | the exact opposite of what it's supposed to do | |
| 18:17:10 | mriedem | because it's not retrying? | |
| 18:17:20 | mriedem | sorry i'm coming in to this halfway | |
| 18:17:38 | edleafe | dansmith: well, if you can look at the rest of my series and assume that the reqspec changes will be reversed and the list of UUIDs will be an RPC param, your feedback would be appreciated | |
| 18:17:48 | dansmith | mriedem: it totally ignores the result of "did my claim work?" | |
| 18:17:58 | mriedem | yeah | |
| 18:18:02 | mriedem | -1 it | |
| 18:18:04 | dansmith | edleafe: well, your set still does the claim in the scheduler | |
| 18:18:07 | dansmith | mriedem: I am | |
| 18:18:14 | mriedem | -1 it, faster :) | |
| 18:18:25 | edleafe | dansmith: 'zactly. | |
| 18:18:34 | edleafe | still think that's cleaner | |
| 18:19:50 | dansmith | edleafe: well, I'd rather we not have the conversation again, but as you wish:) | |
| 18:20:41 | edleafe | dansmith: my hero! | |
| 18:24:12 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add missing rootwrap filter for cryptsetup https://review.openstack.org/462348 | |
| 18:24:37 | openstackgerrit | Jackie Truong proposed openstack/nova master: Fix decoding of encryption key passed to dmcrypt https://review.openstack.org/462674 | |
| 18:32:35 | sdague | lyarwood - Merged openstack/requirements master: Revert "Update eventlet uc to 0.21.0" https://review.openstack.org/464664 | |
| 18:32:47 | sdague | I think you should be back in business, hopefully | |
| 18:38:27 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: update flavor info in server details spec https://review.openstack.org/464723 | |
| 18:38:37 | cfriesen | mriedem: this look okay? ^ | |
| 18:46:52 | mriedem | cfriesen: yup, +2 | |
| 18:47:06 | mriedem | sdague: ^ i assume you also don't want rxtx_factor in the instance.flavor response data | |
| 18:47:26 | mriedem | since if/when we remove rxtx_factor from flavors, we'd have to also remove it from that server response in the same microversion | |
| 18:48:11 | sdague | mriedem: I'm totally fine dumping anything early here that we think would go away later | |
| 18:48:32 | sdague | I really wasn't keen on extra_specs in here | |
| 18:49:01 | sdague | how suck would it be if it wasn't in there? | |
| 18:50:11 | dansmith | extra_specs? it's what a lot of people will want if they're looking for "is this thing numa?" and stuff | |
| 18:50:48 | dansmith | I imagine cfriesen wants extra_specs, for example | |
| 18:52:55 | sdague | hmmm... ok | |
| 18:53:44 | mriedem | yeah i'm good with extra specs | |
| 18:53:52 | mriedem | the admin wants to recreate an instance using a similar flavor | |
| 18:54:00 | mriedem | so they'll want the extra specs too | |
| 18:55:24 | openstackgerrit | Chris Friesen proposed openstack/nova master: fix InvalidSharedStorage exception message https://review.openstack.org/464726 | |
| 18:56:20 | cfriesen | sdague: yeah, it would suck if we didn't have extra-specs for the reasons given | |
| 18:56:33 | sdague | ok, no prob | |
| 18:56:48 | sdague | alright, +2 | |
| 18:57:30 | sdague | cfriesen: so how do you propose the array of extra specs be documented at the api-ref level? | |
| 18:58:15 | dansmith | oh | |
| 18:58:17 | dansmith | so | |
| 18:58:26 | dansmith | users can't see extra specs on regular flavors by default I guess | |
| 18:58:35 | dansmith | so we'd be exposing them here, which would be bad I guess | |
| 18:58:50 | dansmith | I still think this is almost useless if we don't, we just have to separate that out | |
| 18:59:02 | cfriesen | dansmith: the current proposed code uses the same policy as we have now for displaying extra-specs. if the user doesn't have permission the extra-specs key isn't included in the dict | |
| 18:59:08 | dansmith | and then the answer to the api-ref question is "however it's documented in the flavor api" | |
| 18:59:14 | dansmith | cfriesen: ah, perfect | |
| 19:00:08 | sdague | dansmith: well, it's documented poorly there, but keys showing up in the servers doc typically try to have a higher bar of documentation | |
| 19:00:22 | dansmith | okay | |
| 19:00:41 | cfriesen | sdague: dansmith: the proposed nova change is https://review.openstack.org/#/c/434514/ | |
| 19:00:52 | cfriesen | that one doesn't have the rxtx_factor removal though, need to update it | |
| 19:01:14 | sdague | cfriesen: so, you are going to need to break each of those out | |
| 19:01:33 | sdague | I'll leave a comment | |
| 19:02:11 | cfriesen | sdague: in parameters.yaml? I talked about it with mriedem before the summit, we weren't sure how to handle it because each of them is already defined, but we didn't know how to link to them | |
| 19:02:54 | sdague | yeh | |
| 19:03:52 | mriedem | i can confirm that that conversation did in fact happen and i even have tapes of it | |
| 19:04:53 | sdague | ok, the pattern we were working on was https://review.openstack.org/#/c/434514/7/api-ref/source/servers.inc@614 | |
| 19:08:08 | cfriesen | sdague: there are three api calls in servers.inc that return this dict...does that mean I need to describe the dict three times? | |
| 19:09:06 | sdague | cfriesen: it needs to be described every time it's part of the response, but that should just be the same block of field refs | |
| 19:09:09 | cfriesen | sdague: and what about the existing flavor dict fields that are already in parameters.yaml? (flavor_server, flavor_swap, etc) | |
| 19:09:42 | sdague | cfriesen: these are going to have min_microversion on them, so they'll need new entries | |
| 19:10:44 | sdague | the parameters.yaml is sort of 3rd normal form for this data, things aren't hyper normalized, means there is sometimes some copy paste, but it means fixes are more straight forward because they don't unrelatedly change something else you weren't expecting | |
| 19:11:00 | cfriesen | okay, will give it a shot | |
| 19:14:27 | cfriesen | sdague: mriedem: dansmith: on a totally different note, what do you think of https://review.openstack.org/464726 ? This is currently mostly an issue if you use horizon since it defaults to specifying "block_migration=False". | |
| 19:15:43 | sdague | cfriesen: i'm fine with that change | |
| 19:23:29 | mriedem | i don't know what there is not to not like about the original wording | |