| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-15 | |||
| 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 | |
| 19:23:57 | dansmith | it doesn't sound unfine to me when it's not inapplicable due to zero or less other conditionals | |
| 19:45:06 | cfriesen | thanks guys | |
| 20:10:15 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: De-complicate some of the instance delete path https://review.openstack.org/458636 | |
| 20:10:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634 | |
| 20:10:18 | openstackgerrit | Dan Smith proposed openstack/nova master: DNM: Canary test against multi-cell devstack https://review.openstack.org/458537 | |
| 20:10:18 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Debug race in delete-while-booting test https://review.openstack.org/461513 | |
| 20:10:18 | openstackgerrit | Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635 | |
| 20:10:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059 | |
| 21:16:30 | mriedem | mdbooth: https://review.openstack.org/#/c/443951/ was rebased but isn't failing on your test that checks to see if connect_volume and disconnect_volume are taking an instance parameter | |
| 22:18:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: expand checks for SubclassSignatureTestCase https://review.openstack.org/464765 | |
| 22:18:37 | mriedem | mdbooth: fixed here ^ | |
| 22:28:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951 | |