| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-17 | |||
| 11:54:48 | sean-k-mooney | aspiers: ya maybe | |
| 11:55:03 | sean-k-mooney | it woudl depend on when it failed i guess | |
| 11:55:19 | sean-k-mooney | if we have not deleted it form the souce node yet then you should be fine | |
| 11:55:22 | aspiers | I think the idea was maybe that masakari could reinvoke the API in those circumstances | |
| 11:55:50 | sean-k-mooney | ya i think if the db says its still on the source node then you can evac again | |
| 11:55:57 | aspiers | but is there even a way to query the API for the state of an evacuate workflow? | |
| 11:56:15 | sean-k-mooney | but depending on the failure mode the vm could be paused/running on another node at that point | |
| 11:56:19 | aspiers | I vaguely remember that being discussed at past summits | |
| 11:56:30 | aspiers | yeah, the devil is in the details I guess | |
| 11:57:20 | aspiers | I don't think there's ever been enough corporate sponsorship from RH or SUSE to spend time really cleaning up all those corner cases | |
| 11:57:21 | sean-k-mooney | if your contol plane if failing you shoudl really stop what your doing and fix that first then go back to fixing your broken compute nodes | |
| 11:57:36 | aspiers | oh sure, that's a totally different kettle of fish | |
| 11:58:27 | aspiers | compute HA is impossible without a resilient control plane | |
| 11:58:49 | aspiers | same for most workflows | |
| 12:01:01 | aspiers | sean-k-mooney: mriedem makes a good point on https://review.opendev.org/#/c/643578/3//COMMIT_MSG that resurrect is an admin-only command, so "openstack server resurrect" could mislead non-admin users into thinking they can call it | |
| 12:01:42 | aspiers | OTOH I don't agree with his statement "evacuate moves the server to another host (actually it rebuilds it on another host)" | |
| 12:02:04 | sean-k-mooney | aspiers: migrate is an admin command too | |
| 12:02:13 | sean-k-mooney | and that is openstack server migrate | |
| 12:02:42 | aspiers | since a) you can't "move" a server which has already died, and b) it only rebuilds if it was using ephemeral storage | |
| 12:02:44 | sean-k-mooney | the only non admin migration is resize | |
| 12:03:01 | aspiers | sean-k-mooney: right, that's why he was suggesting nesting under "openstack server migrate" | |
| 12:03:07 | sean-k-mooney | no | |
| 12:03:17 | sean-k-mooney | migrate implies it will preserve you data | |
| 12:03:20 | aspiers | but I really don't like that cos resurrect is not a form of migration | |
| 12:03:27 | sean-k-mooney | so that would be worse then evac | |
| 12:03:41 | aspiers | yes, I think we are saying the same thing in different ways :) | |
| 12:04:18 | sean-k-mooney | what im saying is migrate is not an option because migrate implies we move data and we dont in the most common form for evac | |
| 12:04:29 | sean-k-mooney | most deployment have an ephermeal root disk | |
| 12:04:36 | aspiers | yes, that's one good reason to avoid migrate | |
| 12:04:50 | aspiers | and it's not the only one | |
| 12:05:44 | aspiers | at a higher level of abstraction, what you are saying could be reframed as "migrate" implies moving something from A to B without significantly changing it | |
| 12:05:51 | sean-k-mooney | we also discussed having two commands one that guarnetees it preserves your data and one tha that always destroys it | |
| 12:06:04 | aspiers | but you start with something dead on A, and end with something alive on B, that is a big change in state | |
| 12:06:12 | sean-k-mooney | e.g. recreate woudl always destoy any instance and recreate it loasing data | |
| 12:06:15 | aspiers | therefore does not deserve to be called a form of migration | |
| 12:07:02 | artom | Data destruction/preservation also depends on where said data is | |
| 12:07:10 | aspiers | sean-k-mooney: yeah that might be a good approach | |
| 12:07:10 | sean-k-mooney | openstack server migrate --evacuate would guarentte that your data was moved or would not try to do dit | |
| 12:07:36 | aspiers | I mean, having two different commands | |
| 12:07:48 | aspiers | but I don't like migrate --evacuate, for reasons just explained | |
| 12:08:04 | aspiers | I don't really like migrate --resurrect either | |
| 12:08:35 | aspiers | although it bothers me less than migrate --evacuate | |
| 12:09:40 | aspiers | "openstack server recreate" for the ephemeral case and "openstack server resurrect" for the shared storage case feels OK to me | |
| 12:09:50 | openstackgerrit | Surya Seetharaman proposed openstack/python-novaclient master: Allow passing negative values for the locked search_opt in server list https://review.opendev.org/659783 | |
| 12:10:08 | aspiers | but I can see the concern around non-admin users expecting to be able to use it | |
| 12:10:49 | sean-k-mooney | aspiers: well wel could allow openstack server recreate to be non admin | |
| 12:11:40 | sean-k-mooney | its basically a rebuild but optionally to another host | |
| 12:12:20 | aspiers | sean-k-mooney: in what scenarios would non-admin users use that? not if the server is already running right? cos it reuses the old name | |
| 12:13:21 | sean-k-mooney | aspiers: i was implying that openstack server recreate would kill the server if it was running and rescudle it | |
| 12:13:28 | aspiers | oh | |
| 12:13:53 | sean-k-mooney | they would use it if the image or flavor had been updated and they wanted to create the sever with the updated version | |
| 12:14:07 | sean-k-mooney | but keep the same ports and data volumes | |
| 12:14:16 | aspiers | yeah I guess that could be useful | |
| 12:14:45 | aspiers | or if the instance got screwed up somehow, e.g. accidental rm -rf ;-) | |
| 12:15:18 | sean-k-mooney | yep if you instacne are vnfs it would be a neat way to do a software update | |
| 12:15:27 | sean-k-mooney | kindof like in k8s land | |
| 12:15:27 | aspiers | yep | |
| 12:15:45 | sean-k-mooney | e.g. just kill the pod and recreate with the latest version of it | |
| 12:17:54 | aspiers | right | |
| 12:18:21 | aspiers | so are you thinking to update https://review.opendev.org/#/c/643578 to split into two separate commands recreate/resurrect? | |
| 12:18:52 | aspiers | that would work for me, not sure what mriedem will think though | |
| 12:19:12 | aspiers | with both I'd prefer to avoid mentioning the word "migrate" anywhere | |
| 12:19:45 | aspiers | since "migrate" implies avoiding any significant change in state (except the location) | |
| 12:26:28 | aspiers | sean-k-mooney: BTW which timezone are you in? | |
| 12:26:52 | aspiers | I'm guessing somewhere in Ireland? | |
| 12:27:43 | sean-k-mooney | yes | |
| 12:27:57 | sean-k-mooney | im shannon on the west coast of ireland | |
| 12:27:59 | aspiers | nice | |
| 12:28:16 | sean-k-mooney | what timezone i am awake in is not alway the same as where im located | |
| 12:28:22 | aspiers | true for me too ;) | |
| 12:28:35 | aspiers | for some reason I still expect all nova devs to be in north america | |
| 12:28:54 | aspiers | I'm in London | |
| 12:29:32 | openstackgerrit | Gorka Eguileor proposed openstack/nova master: Use os-brick locking for volume attach and detach https://review.opendev.org/614190 | |
| 12:29:41 | aspiers | got a lot of family in Dublin but never been further west than there yet :-( | |
| 13:15:54 | efried | kashyap, aspiers: what's up now? | |
| 13:16:06 | kashyap | efried: It's a change of scenery :-) | |
| 13:16:14 | aspiers | efried: ah, you missed the almight bike osc shed ;-) | |
| 13:16:19 | kashyap | efried: SEV-related, uncontroversial SEV-related | |
| 13:16:27 | kashyap | Err | |
| 13:16:31 | aspiers | oh, that too | |
| 13:16:34 | kashyap | "SEV-related, uncontroversial infra patch" | |
| 13:16:55 | kashyap | aspiers: That's what I assumed efried meant, when he pinged both of us together :D | |
| 13:17:01 | efried | I refer to ==> 3:45:56 AM - kashyap: aspiers: I think your change is ready to merge. Let's check with efried (or stephenfin) when they're about. | |
| 13:17:13 | kashyap | Yep, I correctly guessed. | |
| 13:17:13 | aspiers | yeah, that one | |
| 13:17:32 | kashyap | It is this one: https://review.opendev.org/#/c/655268/ -- "Add infrastructure for invoking libvirt's getDomainCapabilities API" | |
| 13:18:12 | efried | Okay. This isn't really in my, ahem, "domain" of expertise | |
| 13:18:15 | efried | but I'll take a look. | |
| 13:19:30 | ganso | melwitt, dansmith, tonyb: Hi! could you please review https://review.opendev.org/#/c/659338 when you have some time available? Thanks in advance! =) | |
| 13:19:44 | aspiers | efried: it should be pretty simple and not require special expertise | |
| 13:22:05 | efried | aspiers, kashyap: Does this also have to do with video models? | |
| 13:22:19 | efried | https://blueprints.launchpad.net/nova/+spec/libvirt-video-device-models | |
| 13:23:10 | kashyap | efried: No, that getDomainCapabilities() isn't related to video models. | |
| 13:23:15 | efried | ight | |
| 13:23:29 | efried | I see video models in your fake xml, so... | |
| 13:23:46 | efried | uh, I thought I did... | |
| 13:24:00 | aspiers | I guess it could be a future way of detecting available video models? | |
| 13:24:01 | efried | yeah, there. (Chrome's text search has been way slow for me lately) | |
| 13:24:08 | aspiers | if anything needed to do that | |
| 13:24:19 | aspiers | but that's certainly not what's driving the change right now | |