| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 13:58:56 | mriedem | efried: please don't since there are major issues now in that spec | |
| 13:59:10 | mriedem | i.e. persisting RequestSpec.requested_destination now | |
| 13:59:21 | mriedem | please dear sweet baby jesus in heaven no | |
| 13:59:21 | efried | mriedem: Yup, Above comment was before those came in. So now I'll just mark up the issues so boxiang can fix them on the next spin. | |
| 13:59:28 | boxiang | efried: ok | |
| 13:59:44 | efried | mriedem: Did you see the discussion between boxiang and alex_xu in PS13 on persisting? | |
| 13:59:50 | mriedem | yes, and i disagree | |
| 13:59:52 | mriedem | i'm commenting | |
| 14:00:01 | cdent | placement meeting in now ish in #openstack-meeting-alt | |
| 14:00:17 | mriedem | i'm sure dansmith is also not going to be cool with starting to persist RequestSpec.requested_destination now | |
| 14:01:06 | alex_xu | mriedem: we persistent the requested_desitnation now | |
| 14:01:24 | mriedem | alex_xu: no we don't | |
| 14:01:39 | mriedem | if you mean force_hosts/force_nodes, yes, and that's likely a mistake | |
| 14:01:40 | alex_xu | so why we reset the requested_destination when migration? | |
| 14:01:46 | mriedem | that's not requested_destination | |
| 14:01:53 | mriedem | there is literally a field called requested_destination, | |
| 14:02:04 | mriedem | but that's not what reset_forced_destinations resets | |
| 14:02:25 | mriedem | reset_forced_destinations exists solely because we made the mistake of persisting force_hosts/force_nodes | |
| 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 | |