| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 14:12:44 | mriedem | the rest is implementation detail | |
| 14:13:14 | alex_xu | ok, thanks | |
| 14:19:03 | mriedem | restricted to rebuild from cell0 cases | |
| 14:19:03 | mriedem | alex_xu: i think we can cross the rebuild from cell0 bridge for this later if needed, i.e. we could either add the host/hypervisor_hostname parameters to the rebuild api to mirror the server create api (i don't love that idea) or we could do something like store the requested destination in the instance system_metadata when burying it in cell0, and then on rebuild from cell0, use those values and wipe the system metadata so i | |
| 14:21:01 | mriedem | rebuild from cell0 is definitely going to have weird corner cases like this since the rebuild api doesn't mirror the server create api | |
| 14:21:24 | mriedem | alex_xu: btw, are you feeling better? | |
| 14:21:40 | alex_xu | mriedem: yes, like the system_metadata better than the change rebuild API also | |
| 14:22:31 | alex_xu | my initial thoughts is persistent the requested_destination, and reset it when we spawn successful, but I see now, you will hate that :) | |
| 14:22:45 | alex_xu | it is urgly indeed | |
| 14:22:59 | mriedem | my sysmeta + rebuild from cell0 idea isn't much different | |
| 14:23:24 | mriedem | but RequestSpec.requested_destination specifically is off limits for persisting i think - the code already explicitly does not persist it | |
| 14:25:32 | alex_xu | yea | |
| 14:25:40 | alex_xu | at least no better idea yet | |
| 14:26:56 | mriedem | gibi: how would you like me to address this? https://review.openstack.org/#/c/651945/1/nova/cmd/manage.py@2094 | |
| 14:27:04 | mriedem | ? | |
| 14:27:04 | mriedem | call out verify_instance and map_instances specifically | |
| 14:27:07 | kashyap | lyarwood: Heya, on your question on that Secure Boot spec about why not libguestfs API helpw ith "enrolling UEFI keys", I've answered it here: https://review.openstack.org/#/c/506720/8/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@287 | |
| 14:27:30 | kashyap | lyarwood: In short, it doesn't make sense for libguestfs to do so -- as the key enrollment happens in the (virtual) BIOS | |
| 14:28:10 | kashyap | lyarwood: I also ran it past the libguestfs folks, and FWIW, they too agree with what I suggested -- just use the external tool. | |
| 14:28:46 | alex_xu | mriedem: I get better soon in few days, but my daughter get sick also. get blame by whole family :) | |
| 14:28:59 | gibi | mriedem: give the deployer some hint about what to do. If there are nova-manage CLIs the call then mention those | |
| 14:29:14 | mriedem | alex_xu: heh, i suppose from all the travel over the holiday | |
| 14:29:19 | mriedem | gibi: ok done | |
| 14:29:24 | gibi | mriedem: thanks | |
| 14:31:52 | kashyap | lyarwood: (And, thanks for the review!) | |
| 14:32:18 | kashyap | gibi: If you want to re-ACK, in your "copious free time" :-) -- https://review.openstack.org/#/c/506720/ | |
| 14:33:19 | openstackgerrit | Merged openstack/nova stable/ocata: Fix disk size during live migration with disk over-commit https://review.openstack.org/530744 | |
| 14:33:41 | openstackgerrit | Merged openstack/nova stable/ocata: Refix disk size during live migration with disk over-commit https://review.openstack.org/631376 | |
| 14:34:10 | gibi | kashyap: ping me tomorrow please | |
| 14:34:33 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | |
| 14:34:39 | kashyap | gibi: Sure, thanks | |
| 14:34:58 | aspiers | sean-k-mooney, efried: new version of spec^^^ | |
| 14:35:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add --instance option to heal_allocations https://review.openstack.org/651945 | |
| 14:35:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add BFV wrinkle to TestNovaManagePlacementHealAllocations https://review.openstack.org/651948 | |
| 14:36:09 | efried | aspiers: ack, put r on the etherpad | |
| 14:36:13 | aspiers | will do | |
| 14:39:39 | efried | I'm going to take today off, folks. See you tomorrow. o/ | |
| 14:40:56 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | |
| 14:42:41 | dansmith | mriedem: was on a call when you pinged earlier.. do I need to read back? | |
| 14:46:00 | stephenfin | dansmith: I don't know what you're referring to with mriedem, but if you've 2 minutes to sanity check this discussion between efried and I, I'd appreciate it https://review.openstack.org/#/c/651302/1/nova/objects/instance.py | |
| 14:48:40 | dansmith | stephenfin: which, about the notifications? | |
| 14:48:45 | stephenfin | yeah | |
| 14:49:29 | stephenfin | assuming you know. If not, we'll have to go with our (hopefully not too creative) interpretation of what it's doing :) | |
| 14:52:43 | mriedem | dansmith: i don't think so | |
| 14:52:50 | dansmith | mriedem: okay | |
| 14:56:48 | dansmith | stephenfin: I don't really, but I added words | |
| 14:57:00 | stephenfin | Words are good. Thanks | |
| 15:04:03 | openstackgerrit | Merged openstack/nova stable/pike: Fix incompatible version handling in BuildRequest https://review.openstack.org/647557 | |
| 15:14:55 | mriedem | stephenfin: there is something wrong in the reno in https://review.openstack.org/#/c/651291/ plus some other FUP stuff - do you want me to just +W and then you can start a FUP change for that patch? | |
| 15:15:20 | stephenfin | mriedem: Yes please. It's a huge series | |
| 15:15:37 | stephenfin | I've got one follow-up at the end already | |
| 15:15:55 | sean-k-mooney | mriedem: by the way similar to https://bugs.launchpad.net/nova/+bug/1790204 but on the nova side we cant support inplace resize for numa instances due to how the numa toplogy filter or more acurally the nova.virt.hardware module is implemented | |
| 15:15:57 | openstack | Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged] | |
| 15:16:17 | mriedem | stephenfin: ok there are probably enough in here to give it its own fup patch but i'll approve | |
| 15:16:32 | sean-k-mooney | mriedem: so even if ^ is fix for numa instance it can still failt if the host is full | |
| 15:16:44 | openstackgerrit | François Palin proposed openstack/nova master: Include all network devices in nova diagnostics https://review.openstack.org/648123 | |
| 15:19:06 | sean-k-mooney | i had breifly disccused supporing inplacee resize for numa instance downstream as we had a customer request realted to it but wanted to wait until the ptg to see how things panned out | |
| 15:20:12 | mriedem | sean-k-mooney: ok i haven't put any thought into numa for that bug, just the simple resource class cases | |
| 15:20:41 | sean-k-mooney | well its an issue with the resouce track side not placement. | |
| 15:21:07 | sean-k-mooney | if we do "fix" it want i wanted to ask is shoudl i be a bug or a blueprint | |
| 15:21:21 | sean-k-mooney | e.g. is it feature or an oversitght/bug | |
| 15:23:43 | sean-k-mooney | in the context of fixing https://bugs.launchpad.net/nova/+bug/1790204 you can ignore numa. im just wonderinf what i should be filing for the numa same host resize/rebuild case bug/spec/blueprint | |
| 15:23:44 | openstack | Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged] | |
| 15:34:44 | mriedem | stephenfin: another reno fix needed for https://review.openstack.org/#/c/651294/ in a fup somewhere, | |
| 15:34:53 | adrianc | mriedem: Hi, was hoping to get your inputs on https://review.openstack.org/#/c/649345, it seems that _heal_instance_info_cache updates port binding:host_id to point to the compute host. while this is OK for most cases, its problematic for baremetal with Smart NIC https://storyboard.openstack.org/#!/story/2003346 | |
| 15:34:55 | stephenfin | ack | |
| 15:34:56 | mriedem | and probably want melwitt to answer the question about what map_cell_and_hosts is used for | |
| 15:36:24 | sean-k-mooney | adrianc: that periodic task was not intended to run for ironic nodes. at least how its written it was apparently assuming it was running no a vm host | |
| 15:36:46 | mriedem | adrianc: that's a regression due to https://review.openstack.org/#/c/603844/ right? | |
| 15:36:56 | mriedem | before ^ that periodic wouldn't mess with port bindings | |
| 15:37:27 | adrianc | sean-k-mooney: yea i know, hence i think it should not run on BM :) | |
| 15:38:21 | adrianc | mriedem: yes that is correct | |
| 15:38:56 | openstackgerrit | Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458 | |
| 15:39:06 | sean-k-mooney | well for ironic nodes it could update teh port binding for the ironic node instead of skiping but ya we didnt think about that usesece with the previous patch | |
| 15:40:38 | adrianc | is the BM use-case relevant for this type of healing ? | |
| 15:41:05 | mriedem | adrianc: comments inline | |
| 15:41:44 | sean-k-mooney | adrianc: im not sure | |
| 15:41:47 | mriedem | adrianc: before that change the periodic task was essentially read-only as far as the ports are concerned, nova would just refresh it's internal cache | |
| 15:41:48 | adrianc | thanks mriedem, appreciated | |
| 15:41:55 | mriedem | what you need to avoid in the BM case is the update to the port | |
| 15:41:56 | sean-k-mooney | i know we cna do boot form volume with ironic now | |
| 15:42:06 | sean-k-mooney | do we supprot resize/cold migrate | |
| 15:42:46 | sean-k-mooney | in principal if we did then yes we coudl have the same failure cases | |
| 15:43:36 | mriedem | no we don't | |
| 15:45:42 | sean-k-mooney | ok there is no reason that should not be supported for boot form volume ironic instance right? | |
| 15:46:09 | sean-k-mooney | i guess there is the quetion of ephemeral storage | |
| 15:46:36 | mriedem | there was a spec for supporting migration of ironic instances, you could read the details there | |
| 15:47:13 | mriedem | https://review.openstack.org/#/c/449155/ | |
| 15:47:20 | sean-k-mooney | if it was a pure bfv ironic node with no local disk it should work. no im jsut trying to reson about if we would need to validate neutron port for ironic instance in the future | |
| 15:47:22 | mriedem | anyway, that doesn't really have anything to do with this change IMO | |
| 15:47:35 | mriedem | just avoid the port binding update if ironic to get back to the pre-regression behavior | |
| 15:47:57 | sean-k-mooney | ya i was leaving a comment to say somthign similar | |
| 15:48:15 | sean-k-mooney | just wondering if we will need to do something more involed in the future | |
| 15:48:40 | sean-k-mooney | but to fix the regress we jus tneed to not to the port binding update here https://review.openstack.org/#/c/649345/4/nova/compute/manager.py@73311 | |
| 15:49:25 | sean-k-mooney | sorry here https://review.openstack.org/#/c/649345/4/nova/compute/manager.py@7311 | |
| 15:49:31 | sean-k-mooney | extra 3 | |
| 15:50:00 | adrianc | a noob's question here, but why would nova attempt to fix something that ironic did ? that is, ironic is the once who does the actual port binding today right ? | |
| 15:50:07 | mriedem | melwitt: you should review this part of the cells v2 removal series regarding console stuff https://review.openstack.org/#/c/651295/ | |
| 15:50:30 | mriedem | adrianc: the regression was just an oversight | |
| 15:50:42 | sean-k-mooney | adrianc: it depends on the workflow. for spawn yes the virt dirver does the binding | |