Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-01
16:45:57 mriedem but it doesn't actually compare the instances that it finds against self.host
16:46:13 dansmith mriedem: right, it used to, which is why it would delete everything if your hostname changed
16:46:14 mriedem it just says, oh you had an evacuation from this host, we assume it was cool, delete local
16:47:23 mriedem it also says, "with the exception of instances which are in the MIGRATING, RESIZE_MIGRATING, RESIZE_MIGRATED, RESIZE_FINISH task state or RESIZED vm state"
16:47:24 dansmith mriedem: so it might not be nulled out, but if we're in the middle of it starting on the new destination host, we don't know, so if we don't delete it, we'll end up with it in two places
16:47:29 mriedem but i don't see that filtering happening anywhere
16:48:20 dansmith mriedem: yeah that's not from me, that's from dd6fb1246ff2789bd78b772b45e1fcac21eda67a
16:48:29 dansmith which looks like it had a filter in it which is now gone
16:48:41 dansmith that makes no sense to me though,
16:48:47 dansmith since that code already only looks at evacuations
16:49:48 mriedem https://review.openstack.org/#/c/101803/ predates the robustify that used the migration record for filtering
16:50:12 dansmith ah yep
16:50:20 mriedem so we just need to cleanup the comments in here a bit,
16:50:22 dansmith so maybe my bad for not removing that then
16:50:27 mriedem so if we don't take this change,
16:50:41 mriedem and the compute is up and running, need to think about what the RT is going to do
16:51:23 mriedem so we'd remove the allocation on the source node when it starts up
16:51:29 dansmith which is correct
16:51:38 mriedem right b/c the guest was deleted,
16:51:45 mriedem the instance isn't actually gone, and it points at the source host still
16:51:51 dansmith and it looks to me like we would be able to run rebuild on it
16:52:25 dansmith you can run rebuild from error state and it seems like it'll just pick up the evacuation and try again,
16:52:30 dansmith but not if we error it out like this patch does
16:52:55 mriedem the update_available_resource task is going to query for instances on this host/node, and pull this in since it's not deleted
16:53:02 mriedem pass that to _update_usage_from_instances
16:53:27 mriedem which calls _update_usage_from_instance with has_ocata_computes=True
16:53:30 mriedem *False
16:53:38 mriedem assuming you're upgraded
16:54:03 mriedem and it won't recreate the allocation in placement for the source node, which again is correct since we don't have the guest anymore
16:54:16 mriedem if you have ocata computes, it would, but...
16:54:18 mriedem meh?
16:54:18 dansmith we'll create the new allocation during the rebuild
16:54:56 dansmith and when build finishes it'll replace the doubled (due to migration) allocation with the single one for the new host
16:54:59 mriedem the instance wouldn't necessarily be in ERROR state,
16:55:08 mriedem and conductor doesn't set it to ERROR state if it fails to find a host
16:55:08 dansmith it would from that novalidhost
16:55:12 mriedem nope
16:55:17 mriedem it just resets the task_state to None
16:55:18 dansmith it does _set_vm_state_and_notify()
16:55:29 mriedem self._set_vm_state_and_notify(context, instance.uuid,
16:55:30 mriedem 'rebuild_server',
16:55:30 mriedem {'vm_state': instance.vm_state,
16:55:30 mriedem 'task_state': None}, ex, request_spec)
16:55:34 mriedem i've been all up in this code for a week
16:55:35 dansmith oh, does that not set it to error?
16:55:38 mriedem nope
16:55:40 dansmith I see
16:55:46 dansmith well a reset state will put it in error
16:55:52 mriedem if you tell it to :)
16:56:00 mriedem reset-state takes the state you want it in
16:56:01 mriedem i htink
16:56:04 dansmith doesn't reset state default to error?
16:56:11 dansmith no, it's just error or --active as an option I think
16:56:34 mriedem oh i don't know what the CLI does
16:56:37 mriedem but the API doesn't default
16:56:40 mriedem "The state of the server to be set, active or error are valid."
16:56:55 dansmith well, sure
16:57:10 mriedem yeah default on the CLI is 'error'
16:57:38 dansmith I guess we could make it go to error state in here as a change if you think that's better
16:57:51 dansmith I think that won't affect rebuilds because we don't schedule if we do a rebuild, but do for evac
16:58:02 mriedem right we bypass the scheduler for rebuild
16:59:05 mriedem so yeah we could set the instance to ERROR state in conductor...
16:59:17 mriedem if it's an evac
16:59:20 mriedem *failed evac
17:01:31 mriedem well, now i'm not sure what to do
17:03:15 dansmith have a beer?
17:05:40 mriedem i left a summary in https://review.openstack.org/#/c/499237/
17:05:52 mriedem feel free to r'ar or whatever
17:05:56 mriedem i'm going to make lunch
17:58:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Update docs for _destroy_evacuated_instance https://review.openstack.org/500144
18:03:28 openstackgerrit Sean Dague proposed openstack/nova master: DNM: test cells v1/nova-net without screen https://review.openstack.org/500151
18:03:42 sdague mriedem: doesn't seem like cellsv1 job is even in experimental queue for devstack?
18:04:26 mriedem it should be
18:04:45 mriedem used to be anyway
18:05:26 mriedem but yeah i don't see it in there now
18:06:01 mriedem only in experimental for tempest and nova from what i see
18:09:16 mriedem sdague: are you going to add that or should i?
18:10:16 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: link to placement api-ref and history docs from main index https://review.openstack.org/498977
18:10:16 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: link to versioned notification samples from main index https://review.openstack.org/500081
18:26:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove dest node allocation if evacuate MoveClaim fails https://review.openstack.org/499878
18:26:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799
18:28:10 fried_rice Procedural question: can I repoint the spec link for a blueprint? Need to submit a q spec for https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints
18:28:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Update docs for _destroy_evacuated_instances https://review.openstack.org/500144
18:29:11 mriedem fried_rice: i have edit rights
18:29:13 mriedem so i can
18:29:26 fried_rice mriedem Ah, cool. So I'll shoot ya the link once I have it. Thanks.
18:30:42 openstackgerrit Merged openstack/nova stable/pike: Fix nova assisted volume snapshots https://review.openstack.org/498979
18:31:02 mriedem thanks for making me think of this https://www.youtube.com/watch?v=GP1KHL0j0GU
18:40:05 sdague mriedem: either way, I was just surprised. I feel like we had this issue before
18:40:56 mriedem sdague: it comes up every time a devstack change breaks the cells v1 job and blocks nova
18:41:13 mriedem then we fix whatever and forget about it
18:47:00 fried_rice mriedem So the other thing is, this is no longer going to be "use service catalog for endpoints" - it's going to be "use keystoneauth1 discovery for endpoints". Can the blueprint-identifying name be changed; or do I need to file a new blueprint; or do we not care that the identifier is out of sync?
18:47:03 sdague ok, I really thought we merged it the last time :)
18:49:06 mriedem fried_rice: changing the bp name in lp would break the link in the old spec
18:49:09 sdague mriedem: https://review.openstack.org/500169
18:49:14 mriedem we could file a new blueprint and supersede the old one
18:49:32 fried_rice mriedem Okay, I'll do that. Thanks.
18:49:43 fried_rice long as there's a backtrail.
18:49:48 fried_rice supersede works
18:50:37 mriedem sdague: +1

Earlier   Later