| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-17 | |||
| 16:40:16 | sean-k-mooney | .... | |
| 16:40:39 | sean-k-mooney | right now only admins can call /os-hypervisors | |
| 16:40:47 | gmann | but they need scope as project. so any system scope token would not be able to do 'project'-only scope | |
| 16:41:02 | sean-k-mooney | right | |
| 16:41:15 | sean-k-mooney | system scoped tokens should not be project only | |
| 16:41:34 | gmann | yeah so how they get hyperviors ino | |
| 16:41:38 | gmann | info | |
| 16:41:38 | sean-k-mooney | im suggesting project_admin shoudl be able to list the host summaries for all hosts tehy can boot too | |
| 16:42:26 | gmann | yeah that i agree. but keep scope_type as ['system', 'project'] sop that system can list all hyperviros and project can only list what they have access to | |
| 16:42:50 | sean-k-mooney | with role admin | |
| 16:43:02 | gmann | and default to SYSTEM_READER_OR_PROJECT_ADMIN | |
| 16:43:03 | sean-k-mooney | we dont want project member or reader to have acess | |
| 16:43:04 | gmann | yes | |
| 16:43:12 | sean-k-mooney | ya | |
| 16:43:22 | sean-k-mooney | SYSTEM_READER_OR_PROJECT_ADMIN woudl be correct | |
| 16:43:43 | sean-k-mooney | if we do that we dont need to change the api to pass a proejct id | |
| 16:44:03 | gmann | cool and in code we can check and return only the project accessible hypervisors but in that case we need to check the token's scope in nova code | |
| 16:44:17 | gmann | sean-k-mooney: +1 on that. | |
| 16:44:33 | sean-k-mooney | yes on just that one api where we are adding thei fucntionality | |
| 16:44:50 | sean-k-mooney | if we need to expose something lese to project admins we can do that in a similar way | |
| 16:44:59 | gmann | checking token's cope part is little different and new which we need to check how to do | |
| 16:45:01 | sean-k-mooney | but we dont need full system_reader for project admin usecases | |
| 16:45:16 | gmann | agree. | |
| 16:45:24 | sean-k-mooney | i belive it should be in the context object | |
| 16:46:14 | gmann | yes we can do from context only difference is, it is 'system_scope' in context and 'system' in oslo policy side. but not big deal | |
| 16:47:26 | sean-k-mooney | stephenfin: updated https://review.opendev.org/#/c/755109/4 to a +1 if someone wants to +w | |
| 16:53:30 | gmann | stephenfin: sean-k-mooney replied on this what we disucssed - https://review.opendev.org/#/c/763043/1 | |
| 16:53:55 | stephenfin | Ack, will respin shortly. Thanks :) | |
| 17:02:54 | lyarwood | kashyap / stephenfin ; thinking about the machine type enumeration problem a little more, do we care if an instance is using a versioned machine type? | |
| 17:03:14 | sean-k-mooney | lyarwood: kashyap and i disagree | |
| 17:03:17 | kashyap | lyarwood: Do you mean, should we record that or not? | |
| 17:03:24 | sean-k-mooney | lyarwood: i prefer to use the unversioned ones | |
| 17:03:31 | lyarwood | kashyap / stephenfin ; if we record the verioned machine type and always use it wouldn't that stop users getting security updates for free? | |
| 17:03:38 | sean-k-mooney | there are reason to use the versioned ones | |
| 17:03:46 | sean-k-mooney | livemigration/upgrades mainly | |
| 17:03:47 | lyarwood | sean-k-mooney: right I think I'm with you if the ABI remains the same | |
| 17:04:02 | sean-k-mooney | the machine type partly defines the abi | |
| 17:04:15 | sean-k-mooney | so it wont nessisarly remian the same but its largly the same | |
| 17:04:32 | sean-k-mooney | thing that can change are the max number of cores supported for example | |
| 17:04:44 | sean-k-mooney | but it should be backward compatible | |
| 17:04:56 | lyarwood | yeah | |
| 17:04:56 | kashyap | lyarwood: Just so I get you: we're referring to CentOS/RHEL-based versioned machine types, yeah? (And not the upstream QEMU's per-release machine types) | |
| 17:05:08 | sean-k-mooney | e.g. a q35-1 guest shoudl be upgradable to a q35-2 machine type | |
| 17:05:28 | kashyap | sean-k-mooney: Well, wait. That sentence doesn't make sense | |
| 17:05:55 | kashyap | To remind: when you migrate an instance with machine type q35-1, it *remains* q35-1 on the destination | |
| 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 | 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:15 | kashyap | lyarwood: Not sure if we're on track with your original question | |
| 17:07:28 | lyarwood | kashyap: yeah this is still on the original question | |
| 17:07:37 | sean-k-mooney | kashyap: well if you just use q35 in your nova.conf | |
| 17:07:37 | openstackgerrit | Merged openstack/nova-specs master: Add modernize-os-hypervisors-api spec https://review.opendev.org/755109 | |
| 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 | lyarwood | does anyone actually care about running on a specific version of a machine type? | |
| 17:12:38 | sean-k-mooney | lyarwood: do you have my hw:stable_abi extra spec in your spec | |
| 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. | |