Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-14
18:36:31 mriedem users don't evacuate
18:36:33 mriedem since it's a migratoin
18:36:34 mriedem *migratoin
18:36:36 mriedem damn
18:36:37 mriedem migration
18:36:41 mriedem admins evacuate
18:36:47 feeblepipes mriedem: and who rebuilds?
18:36:58 mriedem users that want the same attached volumes but a new image
18:37:02 mriedem you can specify a new image with rebuild
18:37:08 feeblepipes le sigh... ok.
18:37:10 mriedem basically it's a server create to over
18:37:27 mriedem same host though i believe
18:37:31 feeblepipes do-over you mean?
18:37:46 mriedem the rebuild happens on the same host that the instance already lives on
18:37:51 mriedem it would have to for the networking and volumes
18:38:06 mriedem now rebuild + volume-backed root disk....
18:38:11 mriedem i'd have to investigate
18:38:43 mriedem we track evacuations with the migrations table since it's a type of move
18:38:57 mriedem that was part of dan's robustify evacuate changes in i think mitaka
18:39:09 mriedem so that when the old host comes back up it doesn't delete all of your instances that are now running somewhere else
18:39:15 mriedem because that was a real thing
18:39:22 mriedem and could wipe out your entire vcenter cluster
18:39:24 mriedem you're welcome
18:39:50 mriedem i.e. we check the migrations table to see if an instance was evacuated on startup of the old host
18:40:27 mriedem https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L635
18:42:40 feeblepipes mriedem: +W'd that spec. working on mgagne's one now.
18:44:09 mriedem i guess i should read the list migration types one
18:45:00 mriedem sfinucan: the spec for this is approved now so you can drop the procedural -2 https://review.openstack.org/#/c/430608/
19:00:33 openstackgerrit Dan Peschman proposed openstack/nova master: Option to always create network metadata information as static https://review.openstack.org/336293
19:49:01 mriedem feeblepipes: i left some comments in https://review.openstack.org/#/c/407237/ too
19:49:23 mriedem feeblepipes: i'm not sure why the various task state transitions were left in there, unless that was to show what in-progress meant for each type of migration?
19:49:35 feeblepipes yeah, maybe.
19:49:39 mriedem those don't line up with what the supported migration statuses are though
19:49:54 mriedem also, i've always found it odd that we filter what we return to just in-progress migrations
19:50:10 mriedem that is an artifact of when os-migrations was added, and i think it was only there for the cancel action
19:50:16 mriedem so those were tightly coupled
19:50:40 mriedem i don't think we should restrict the returned set to in-progress migrations by default, but rather allow a status filter parameter
19:54:37 mriedem i might blast the ML on that one unless there is a good reason i'm missing
19:54:40 mriedem i'd also like operator feedback
19:54:55 feeblepipes cool with me.
19:55:06 feeblepipes almost done with the VGPU spec.
20:01:10 sdague mriedem: hmmm... that does make me wonder if I could pillage instance actions in a reasonable way then for statistics. Perhaps I'll ponder that next week
20:01:26 mriedem and that reminds me to ask about instance actions for shelve in the ops list
20:05:49 sdague I think it would mostly be useful if we put something into nova-manage that would build statistics based on it for dump
20:11:30 mriedem yeah
20:11:40 mriedem also, crap, but we return db primary keys for the migrations api
20:11:56 feeblepipes sfinucan: -1 from me for a few remaining niggles on https://review.openstack.org/#/c/450122/, but it's pretty close.
20:12:04 mriedem so when you want to cancel an in-progress live migration out of the api, you pass in the id but with multi-cell we won't know which cell it's in
20:12:08 feeblepipes mriedem: yeah... that needs to die in a fire.
20:12:24 mriedem feeblepipes: well that's dying for services and compute nodes in the api, but i missed migrations
20:12:30 feeblepipes mriedem: also, since migrations list runs in all cells, you get duplicate migration IDs. fun!
20:12:38 mriedem feeblepipes: true story
20:12:43 mriedem i don't think dansmith has fixed that one yet
20:12:49 mriedem which is why we didn't think about it earlier
20:13:19 feeblepipes mriedem: it's not terribly important really... now that we removed the top-level os-migrations/ REST resource, it's not like there's a global key.
20:13:42 feeblepipes mriedem: meaning it's always under servers/.../os-migrations
20:13:58 feeblepipes mriedem: so, no harm no foul. the primary key is within the server's cell.
20:14:05 feeblepipes mriedem: but still, annoying and should die in a fire.
20:18:59 mriedem feeblepipes: oh you're right yeah, we'll lookup the instance via uuid, and when we do that we target the context to the cell that the instance is in
20:19:04 mriedem so looking up the migration by id after that is ok
20:19:05 mriedem whew
20:19:09 feeblepipes ya
20:19:29 feeblepipes #success mriedem said I was right.
20:19:31 openstackstatus feeblepipes: Added success to Success page
20:26:15 mriedem ha
20:33:10 feeblepipes mriedem: so, quick question on mgagne's extend volume spec...
20:33:37 feeblepipes mriedem: we didn't add a microversion when we added the network-vif-deleted external event. why are we requiring one here?
20:34:14 mriedem feeblepipes: i think that predated microversions
20:34:17 feeblepipes mriedem: and the answer could easily be "we didn't have microversions then"... I just honestly don't know.
20:34:20 feeblepipes ah, ok.
20:34:20 mriedem that was like havana or icehouse
20:34:26 feeblepipes sdague: any memory of above?
20:34:32 feeblepipes mriedem: k.
20:34:48 mriedem i remember talking about that at the first midcycle in provo utah
20:34:49 feeblepipes mriedem: I'm going to approve this then.
20:34:50 mriedem which was icehouse
20:35:24 mriedem yeah https://github.com/openstack/nova/commit/ce936ea5f3ae0b4d3b816a7fe42d5f0100b20fca
20:35:35 mriedem f man, to the t
20:35:37 mriedem icehouse it was
20:35:58 feeblepipes mriedem: +W'd.
20:36:34 feeblepipes mriedem: any more high-priority specs you need reviewed?
20:37:06 feeblepipes mriedem: what about the "use service catalog for glance" one? I think that's actually a really good one to do and is a relatively small amount of work.
20:37:38 feeblepipes mriedem: well, technically it's not just glance, but all services.
20:37:39 mriedem there was a spec for that?
20:37:47 mriedem i thought we were just doing that
20:37:49 mriedem and had been
20:37:53 feeblepipes https://review.openstack.org/#/c/454983/
20:38:08 feeblepipes looks new :)
20:38:15 mriedem heh, i don't think we really need a spec for that,
20:38:16 feeblepipes still has that new car smell.
20:38:20 mriedem that's been part of the move to ksa for awhile now
20:38:23 feeblepipes ya
20:38:53 mriedem let me read quick
20:41:10 feeblepipes mriedem: cburgess has responded positively on your suggestion for not limiting migrations in the listing. I say based on that feedback, we don't do it. :P
20:42:22 mriedem ha
20:42:24 mriedem oh chet
20:42:27 mriedem always the punching bag
20:42:50 feeblepipes indeed.
20:44:18 mriedem i'm going to pull the service catalog one down and fix some nits then +2
20:51:39 feeblepipes mriedem: k, lemme know when you do and I'll review.

Earlier   Later