Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-15
13:05:10 stephenfin gibi: If you have a chance, could you look at https://review.openstack.org/#/c/651302/1/nova/objects/instance.py and see if I'm doing anything particular wrong?
13:07:57 kukacz hi, I wonder if nova handles situation of live-migrating an instance with config drive from rbd-backed compute host to file-backed compute host and vice versa? it seems I'm stuck in Ocata with instance resized from rbd-backed to raw-backed compute node, not willing to live-migrate in the other direction
13:09:00 kukacz it's a volume-booted instance. the issue is about config drive
13:19:37 gibi stephenfin: replied to the notification part. I wasn't to helpful, sorry.
13:19:53 stephenfin gibi: Neither was I so that makes two of us. Thanks :)
13:21:22 gibi stephenfin: I think you need dansmith for this
13:37:46 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Undeprecate and move the 'dhcp_domain' option https://review.openstack.org/480616
13:37:46 openstackgerrit Stephen Finucane proposed openstack/nova master: Handle unsetting '[DEFAULT] dhcp_domain' https://review.openstack.org/652662
13:43:48 efried boxiang: Do you mind if I do a quick edit of https://review.openstack.org/#/c/645458/ for grammar?
13:51:08 mriedem lyarwood: questions in your swap volume migration_status patch https://review.openstack.org/#/c/637224/
13:51:16 mriedem lyarwood: looks like there could be some weird edge cases
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

Earlier   Later