| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-17 | |||
| 16:01:50 | sean-k-mooney | i said it was fine but i ment it looked good | |
| 16:12:26 | tacco | sean-k-mooney: thanks that helped, now i have to see how to get the config part into os_nova for openstack-ansible to persist my change somewhere upstream. :D | |
| 16:12:50 | sean-k-mooney | :) | |
| 16:35:19 | gmann | stephenfin: sean-k-mooney replied on review. are we allowing hypervisor info for projects for use case of boot server on host? | |
| 16:35:32 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Update modernize-os-hypervisors-api spec https://review.opendev.org/763043 | |
| 16:36:42 | stephenfin | gmann, sean-k-mooney, bauzas, gibi: I've split that potential policy change out so we can debate the merits of it separately ^ | |
| 16:37:51 | gibi | stephenfin: ack, thanks | |
| 16:37:58 | gmann | stephenfin: +1, | |
| 16:38:15 | sean-k-mooney | gmann: yes | |
| 16:38:33 | sean-k-mooney | gmann: i dont think we shoudl be using system_read+proejct_admin | |
| 16:38:47 | gmann | what we can do is keep GET /os-hypervisors for ['system' and 'projects'] and only return list of hypervisors for project what all they are access to via aggregate metadata otherwise emtpy | |
| 16:39:12 | stephenfin | sean-k-mooney: You okay to discuss separately, yeah? Can you toggle your -1 if so? | |
| 16:39:15 | gmann | sean-k-mooney: well if we make only project then system would not be able to list hypervisor at all | |
| 16:39:29 | sean-k-mooney | stephenfin: yep if you file a second spec im happy to defer to there | |
| 16:39:41 | gmann | and adding/removing the host are system level operation right | |
| 16:39:42 | stephenfin | See https://review.opendev.org/763043 | |
| 16:39:46 | sean-k-mooney | gmann: system would | |
| 16:39:53 | sean-k-mooney | gmann: its an additive change | |
| 16:40:09 | sean-k-mooney | fithe now yould admins can call /os-hyperviors | |
| 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 | |