| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 14:02:38 | boxiang | mriedem: the requestec_destination of request spec is always null in db now? | |
| 14:02:40 | alex_xu | oh... | |
| 14:03:46 | mriedem | i've commented if you want details and history/examples https://review.openstack.org/#/c/645458/ | |
| 14:03:52 | mriedem | but i've been working on fixing these bugs for a long time now | |
| 14:03:59 | mriedem | so i don't really want to undo that work here | |
| 14:04:54 | alex_xu | ok, if so, I agree with that, that is what i'm thinking initial until I missed read reset_forced_destinations method | |
| 14:05:03 | mriedem | that method is a hack | |
| 14:05:09 | mriedem | to workaround persistence we shouldn't be doing | |
| 14:05:29 | alex_xu | but I'm pretty ensure we can migration the instance again without the initial forced host | |
| 14:05:59 | mriedem | yes we can because of reset_forced_destinations | |
| 14:06:17 | mriedem | otherwise you couldn't ever evacuate or live migrate a forced host/node server | |
| 14:06:18 | alex_xu | without the initial of requested_destination :) | |
| 14:06:33 | alex_xu | yes | |
| 14:08:07 | mriedem | the main concern / justification i saw for persisting requested_destination in this spec was for the rebuild from cell0 case, | |
| 14:08:27 | mriedem | but i think i've already pointed out things in that rebuild from cell0 spec that the user will lose from the initial server create if they rebuild from cell0 | |
| 14:08:45 | mriedem | because the rebuild API doesn't match the server create parameters 1:1 | |
| 14:09:25 | mriedem | https://review.openstack.org/#/c/648686/1/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@72 | |
| 14:10:35 | alex_xu | mriedem: yes, agree with that. so that should be resolved by rebuild spec, right? | |
| 14:11:04 | alex_xu | or you want to process in this spec | |
| 14:11:38 | alex_xu | at least, there need a way to persistent requested_destination for the fail boot instance | |
| 14:11:47 | mriedem | alex_xu: i really don't want to talk about rebuild from cell0 in *this* spec :) | |
| 14:11:56 | alex_xu | mriedem: cool :) | |
| 14:12:05 | mriedem | "there need a way to persistent requested_destination for the fail boot instance" is debateable | |
| 14:12:23 | alex_xu | ha | |
| 14:12:36 | mriedem | i agree with your assertion in boxiang's spec that we should just say you can move the server even if you requested that it was built on a specific host | |
| 14:12:44 | mriedem | the rest is implementation detail | |
| 14:13:14 | alex_xu | ok, thanks | |
| 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:19:03 | mriedem | restricted to rebuild from cell0 cases | |
| 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 | call out verify_instance and map_instances specifically | |
| 14:27:04 | mriedem | ? | |
| 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 ? | |