| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-14 | |||
| 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. | |
| 20:53:04 | feeblepipes | cfriesen: nice "does anyone actually use shelve?" :) | |
| 20:53:11 | feeblepipes | cfriesen: my feelings precisely. | |
| 20:53:14 | feeblepipes | should die in a fire :) | |
| 20:53:46 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Use service catalog to get endpoint URLs https://review.openstack.org/454983 | |
| 20:53:46 | mriedem | feeblepipes: ^ | |
| 20:53:53 | feeblepipes | danke | |
| 20:54:16 | mriedem | sdague: yeah nova-manage is probably what we have to use since we can't list instance actions out of the api for all tenants | |
| 20:55:03 | mriedem | sdague: if you wanted to brain dump ideas for an interface in a blueprint it could be hacked on | |
| 20:55:16 | mriedem | like, list total number of all actions or something | |