| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-17 | |||
| 17:06:01 | sean-k-mooney | the abi between verions should change additivly | |
| 17:06:08 | kashyap | ... until one explicitly changes it via nova.conf. | |
| 17:06:12 | sean-k-mooney | kashyap: yes i never said migrate | |
| 17:06:28 | sean-k-mooney | i said upgrade i actully ment via a hard reboot | |
| 17:06:34 | kashyap | sean-k-mooney: Err, my mind read the "upgradable" as "migratable". Silly me! | |
| 17:07:00 | kashyap | sean-k-mooney: Even in the case of "upgrade", libvirt won't gratuitously update it, you have to explicitly request it. | |
| 17:07:15 | kashyap | lyarwood: Not sure if we're on track with your original question | |
| 17:07:15 | sean-k-mooney | you can expect that a guest booed on an older vers should be able to boot in the newer verion of the same overall type | |
| 17:07:28 | lyarwood | kashyap: yeah this is still on the original question | |
| 17:07:37 | openstackgerrit | Merged openstack/nova-specs master: Add modernize-os-hypervisors-api spec https://review.opendev.org/755109 | |
| 17:07:37 | sean-k-mooney | kashyap: well if you just use q35 in your nova.conf | |
| 17:07:48 | lyarwood | kashyap: so my spec as written will track the versioned machine type | |
| 17:07:57 | sean-k-mooney | then since we destroy and recreate teh domain it will use the new one that the q35 alis now points too | |
| 17:08:03 | kashyap | lyarwood: So ... on the security updates: they're not tied to machine types often; most fixes in machine types are typically garden-variety "bug fixes" | |
| 17:08:06 | lyarwood | kashyap: but the issue with that is that you can never move from that specific version without rebuilding the ntire instance | |
| 17:08:18 | lyarwood | entire* | |
| 17:08:33 | sean-k-mooney | lyarwood: well really it should track the unversioned one | |
| 17:08:39 | sean-k-mooney | unless its set in the nova.conf | |
| 17:08:42 | lyarwood | sean-k-mooney: that's what I'm getting at | |
| 17:08:44 | sean-k-mooney | in which case it should use that | |
| 17:08:58 | lyarwood | sean-k-mooney: even then I think we should track the unversioned machine type | |
| 17:08:59 | kashyap | sean-k-mooney: Lee's question is, what *if* the guest is explicitly using the versioned machine type | |
| 17:09:11 | sean-k-mooney | if you had not set it the expecation is that it will change when you hard-reboot if you did a yum update and updated libvirt/qemu | |
| 17:09:35 | sean-k-mooney | kashyap: if the guest is useing a verioned machinve type in the image you dont need to do anything | |
| 17:09:48 | sean-k-mooney | if the guest is useing a version machine tyep from the config then use the config value | |
| 17:10:05 | sean-k-mooney | the upgrade to a newer one was ment to be handeled by the new recreate api | |
| 17:10:14 | sean-k-mooney | which we rejected so there is no upgrade path now | |
| 17:10:31 | lyarwood | well just using the alias | |
| 17:10:43 | lyarwood | that's the only way to provide an upgrade path to users | |
| 17:10:59 | sean-k-mooney | right but on waht operation would it upgrade | |
| 17:11:18 | kashyap | lyarwood: I think the clearest way to get understanding here is to lay out some example scenarios | |
| 17:11:19 | lyarwood | move or hard reboot | |
| 17:11:25 | lyarwood | assuming the underlying QEMU had been updated | |
| 17:11:32 | kashyap | lyarwood: I've writte up some for RHOS QE for cold migration, live and evacuate scenarios | |
| 17:11:43 | sean-k-mooney | i guess i could by that | |
| 17:12:01 | kashyap | I can clean that up and provide a link, as lay out the impliciations. And that allows one to better reason about it, IMHO | |
| 17:12:06 | sean-k-mooney | resize,hardreboot, unshelve, rebuild and cold migrate | |
| 17:12:38 | sean-k-mooney | lyarwood: do you have my hw:stable_abi extra spec in your spec | |
| 17:12:38 | lyarwood | does anyone actually care about running on a specific version of a machine type? | |
| 17:12:46 | lyarwood | sean-k-mooney: no | |
| 17:12:58 | sean-k-mooney | lyarwood: we do for ffu | |
| 17:13:06 | sean-k-mooney | but beyond that im not sure | |
| 17:13:20 | lyarwood | sean-k-mooney: why? Wouldn't that be covered by LM | |
| 17:13:34 | sean-k-mooney | yes kind of | |
| 17:13:59 | sean-k-mooney | it more we want to pin the new host to the old verion untill the rolling upgrade is complete | |
| 17:14:00 | sean-k-mooney | i think | |
| 17:14:19 | sean-k-mooney | so that we can technically migrate form new to old if we need too eventhough we say dont do that | |
| 17:14:39 | sean-k-mooney | changing the machine_type is ment to be a post upgrade step | |
| 17:14:49 | lyarwood | well you could still technically do that with FFU | |
| 17:15:12 | lyarwood | actually no you couldn't ignore me | |
| 17:15:28 | lyarwood | and agreed with post upgrade for changing default machine types | |
| 17:16:11 | kashyap | A factor to consider: if you track the unversioned 'pc' or 'q35', it always aliases to the latest available versioned machine type on the box. | |
| 17:16:29 | sean-k-mooney | from a donwstream point of view what we said was new installs should use the new default, existing installs should be upgrade with the old default then the default shoudl be changed as a post upgrade action | |
| 17:17:26 | sean-k-mooney | kashyap: yes but if you have not express an opipion in the image and the config is either unset or set to the aliase i think that is the right thing to track anyway | |
| 17:17:45 | kashyap | sean-k-mooney: Yep, that I agree with. | |
| 17:17:55 | sean-k-mooney | the edge case is if you have a versioned machine type in the config | |
| 17:18:06 | sean-k-mooney | i was suggesting recodign that | |
| 17:18:18 | sean-k-mooney | but then we cant really allow it to change on hard reboot | |
| 17:18:30 | lyarwood | it wouldn't | |
| 17:18:33 | sean-k-mooney | it would have to be resize or rebuld only | |
| 17:18:54 | sean-k-mooney | maintain the machine type on cold or live migate | |
| 17:18:55 | lyarwood | if a versioned machine type is recorded the only way to change it would be with a rebuild | |
| 17:19:14 | sean-k-mooney | lyarwood: only rebuild or rebuild/resize | |
| 17:19:26 | lyarwood | sean-k-mooney: rebuild/resize sorry | |
| 17:19:37 | sean-k-mooney | so the elephant in the room | |
| 17:19:41 | lyarwood | sean-k-mooney: actually can you proivide the machine type via a flavor | |
| 17:19:41 | sean-k-mooney | what about evacuate | |
| 17:19:49 | sean-k-mooney | lyarwood: no | |
| 17:19:54 | sean-k-mooney | but we could | |
| 17:19:57 | lyarwood | sean-k-mooney: then just rebuild | |
| 17:20:05 | sean-k-mooney | that does not work then | |
| 17:20:09 | lyarwood | sean-k-mooney: and evacuate uses rebuild | |
| 17:20:09 | sean-k-mooney | rebuild is distructive | |
| 17:20:21 | sean-k-mooney | and for secuity reason we do need a way to change this | |
| 17:20:34 | sean-k-mooney | which is one of the reason i had recreate | |
| 17:20:40 | lyarwood | well that's no different to the situation we are in today | |
| 17:21:01 | sean-k-mooney | no today you jsut change the config option and hardreboot | |
| 17:21:13 | lyarwood | that a user has no access to | |
| 17:21:21 | sean-k-mooney | or if its using the aliase just package update and reboot | |
| 17:21:25 | lyarwood | that's basically the same as a db update | |
| 17:21:35 | sean-k-mooney | it is yes | |
| 17:21:42 | sean-k-mooney | we need a way for an admin to update it | |
| 17:21:46 | sean-k-mooney | that is not a db update | |
| 17:21:47 | lyarwood | if you're using an alias it's just a hard reboot with the new approach still | |
| 17:21:50 | sean-k-mooney | we dont need a way for a user | |
| 17:22:04 | sean-k-mooney | lyarwood: yep which is why i like aliasis amoung other things | |
| 17:22:12 | sean-k-mooney | lyarwood: what about a nova manage command | |
| 17:22:26 | lyarwood | sean-k-mooney: yup that could work | |
| 17:22:33 | sean-k-mooney | to update the machine type in a suppotable way | |
| 17:23:11 | sean-k-mooney | ideally support either the instance uuid/uuids or a host | |
| 17:23:35 | lyarwood | but it still looks like we can't enumerate all of the possible machine types so I'm back to using a StringField | |
| 17:23:42 | lyarwood | gah | |
| 17:23:50 | sean-k-mooney | well ya its a sting filed | |
| 17:23:56 | sean-k-mooney | they are different per disto | |
| 17:24:02 | lyarwood | yup | |
| 17:24:05 | sean-k-mooney | and you can add your own by just adding a file | |
| 17:24:35 | lyarwood | I indeeed, right need to help with childcare and then I'll update the spec | |
| 17:24:37 | sean-k-mooney | i know some people have done that to work around some default in the past realted to >2TB vms | |
| 17:24:48 | lyarwood | thanks stephenfin, kashyap, sean-k-mooney! | |
| 17:36:32 | ralonsoh | sean-k-mooney, just a heads-up: https://review.opendev.org/740067 | |