| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-05 | |||
| 16:46:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: Default native threading for sch, api and metadata https://review.opendev.org/c/openstack/nova/+/965924 | |
| 16:46:41 | gibi | dansmith: sean-k-mooney: ^^ this (and its ancestors) are fixed up now based on the yesterday's dicussion | |
| 17:02:30 | opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | |
| 17:19:30 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Implement placement:same_subtree flavor extra spec https://review.opendev.org/c/openstack/nova/+/966205 | |
| 17:32:13 | opendevreview | Merged openstack/nova-specs master: Copy the spec approved in 2025.2 to 2026.1 https://review.opendev.org/c/openstack/nova-specs/+/966151 | |
| 18:00:36 | melwitt | dansmith: I think I have to make more updates to the vTPM patches :( sean commented on the spec review about not having any new sys meta key for storing the TPM security policy https://review.opendev.org/c/openstack/nova-specs/+/961564/3/specs/2026.1/approved/vtpm-live-migration.rst#181, | |
| 18:01:51 | melwitt | in the current version, I still used a sys meta key to stash the policy because I was thinking of a scenario where the operator may want to disallow 'user' (legacy) vTPM instances and I had been thinking I needed to store it to know to add the USER required trait for scheduling (to prevent scheduling of 'user' if configured). but I guess I could just make the logic in the request filter add the USER trait if there is vTPM but no policy | |
| 18:01:51 | melwitt | in the flavor instead | |
| 18:03:49 | melwitt | dansmith: what do you think? | |
| 18:12:03 | dansmith | melwitt: ack, yeah I guess I thought we were still going to stamp it in the sysmeta regardless of where the decision came from, but I guess we can just make that "virtual" and always look at the flavor | |
| 18:12:17 | dansmith | I hate to have to revise it again and do my testing again, but.. yeah | |
| 18:13:20 | melwitt | dansmith: yeah, I'm getting confused thinking about it but I'm remembering now that was I was thinking was that we would need to be able to differentiate between a legacy vTPM instance vs a new defaulted 'user' vTPM instance, | |
| 18:14:44 | melwitt | because if the operator wanted to disallow new 'user' instances, I think they also wouldn't want to block pre-existing legacy instances from doing things like resize | |
| 18:14:47 | melwitt | in order to tell the difference between an old vTPM instance and a new defaulted one, we would have to store it in sys meta. that's why I did it | |
| 18:16:12 | melwitt | but sys meta is not viewable in the scheduler request filter ... so I'm not sure how that could be | |
| 18:19:27 | dansmith | well, before, we needed to know if they had opted into user or were being defaulted, so that we didn't migrate against their will, right? | |
| 18:19:40 | dansmith | but if we only change via resize then we don't need to know the difference.. user is user until resize and then it's not user | |
| 18:19:52 | dansmith | s/not/potentially not/ | |
| 18:21:37 | melwitt | yeah...thinking | |
| 18:23:31 | melwitt | this is another place where I see use of the sys meta key https://review.opendev.org/c/openstack/nova/+/941483/35/nova/virt/libvirt/driver.py#10803 if we want to be able to set the LibvirtLiveMigrateData fields to None for new defaulted instances | |
| 18:24:06 | melwitt | for the object backleveling check | |
| 18:24:42 | dansmith | right but you'll just do instance.flavor.get('security', 'user') above right? | |
| 18:24:50 | dansmith | oh, well, | |
| 18:25:03 | dansmith | you'll actually do something like: | |
| 18:25:22 | dansmith | istpm = instance.flavor.get('tpm_model', None) | |
| 18:25:51 | dansmith | if istpm: security = instance.flavor.get('security', None) else: security = None | |
| 18:25:56 | dansmith | and then the rest will be the same right? | |
| 18:28:40 | melwitt | it's confusing because I think you would only want to set those to None if the instance is new enough for the fields to be relevant ... or maybe that doesn't matter? | |
| 18:29:41 | dansmith | if it has a model but no security, then it's user | |
| 18:29:47 | dansmith | if it has a model and security, then $security | |
| 18:29:53 | melwitt | whether it's a legacy vTPM instance vs a new defaulted 'user' vTPM instance | |
| 18:30:04 | dansmith | if it has no model, then that's your None case, regardless of if it's new or old | |
| 18:30:48 | melwitt | hm yeah, ok. | |
| 18:31:09 | dansmith | I mean.. right? | |
| 18:31:58 | melwitt | yeah I had kept thinking we wouldn't want to set None if it's legacy, but I guess it doesn't really hurt anything or matter | |
| 18:32:24 | melwitt | in my mind it was like, "if legacy, don't do anything different than it is today" | |
| 18:32:57 | dansmith | no, legacy user and new user are the same AFAIK | |
| 18:33:01 | melwitt | i.e. it doesn't matter if we prevent backport of a live migrate object for legacy vTPM because it can't happen | |
| 18:33:47 | dansmith | well, technically user migrations can happen if the user is the one doing the migration (if the admin has granted them that right) so we should have that work right? | |
| 18:34:21 | dansmith | but like if I want to delegate live migrate ability to project manager role or something that should work | |
| 18:34:23 | melwitt | no, 'user' mimics legacy completely including not being live migratable | |
| 18:34:37 | dansmith | or if the user doing the migration has been granted access to the key in barbican, it should work fine right? | |
| 18:35:05 | melwitt | for 'host' yes | |
| 18:35:34 | dansmith | okay I'm confused.. you're building in "user security is never migratable just because" behavior? | |
| 18:35:43 | melwitt | but yeah, for 'user' LibvirtLiveMigrateData should never be in play | |
| 18:36:18 | melwitt | that's what the spec intended anyway, 'user' just means legacy same-as-today behavior | |
| 18:37:01 | melwitt | (i.e. live migrate rejected in the API) | |
| 18:37:54 | dansmith | hrm | |
| 18:38:11 | dansmith | I was assuming that user would be migratable if the key was accessible to the user doing the migration | |
| 18:38:50 | melwitt | it could be, but the spec as far as I understood it left a mode for exact-same-as-today | |
| 18:38:53 | dansmith | because it should be basically "deployment" at that point in terms of setting it up on the remote side, just using the context token instead of the service user | |
| 18:39:21 | melwitt | right | |
| 19:08:09 | mikal | sean-k-mooney (and I guess anyone else): https://review.opendev.org/c/openstack/kolla-ansible/+/966111 might be of interest. The author is asserting that Nova supports having more than one graphical console enabled at any given time, which is news to me. I tried pointing him at the docs but it hasn't worked out for me. Honestly, maybe I'm wrong. A | |
| 19:08:10 | mikal | second opinion would be appreciated. | |
| 19:09:08 | sean-k-mooney | mikal: so yes it can be on diffent host | |
| 19:09:19 | sean-k-mooney | and also i think it did work a long long long time ago | |
| 19:09:34 | sean-k-mooney | but i have no idea if it actully works today with the libvirt driver | |
| 19:09:44 | sean-k-mooney | are they asseting that you can have both on the same host | |
| 19:10:13 | sean-k-mooney | we have config option tha twoudl imply that and the console proxy coudl handel that | |
| 19:10:31 | mikal | To my reading of their comments, they agree you can only have one type per instance, but that different instances can have different console types. I don't think this is true, but maybe I'm on drugs. | |
| 19:10:38 | sean-k-mooney | but teh only time i have mixed it is vnc or spice for livbirt and the serial proxy for ironic | |
| 19:10:56 | mikal | So yeah, I think they think they can mix on a single nova host, not say have different ones per cell. | |
| 19:11:12 | sean-k-mooney | well its not even at the cell level | |
| 19:11:20 | sean-k-mooney | it will work at the indigiual compute node level | |
| 19:11:36 | sean-k-mooney | i can quickly check in devstack i guess | |
| 19:13:18 | mikal | I find https://review.opendev.org/c/openstack/kolla-ansible/+/966111/2/ansible/roles/nova-cell/templates/nova.conf.j2 quite hard to read, but I don't see any logic there which stops it from rendering a nova.conf which has both VNC and SPICE enabled in one nova.conf, which I think we're agreeing wont work? | |
| 19:14:08 | sean-k-mooney | mikal: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7825 | |
| 19:14:20 | sean-k-mooney | so it is posibel in the code to have spice and vnc | |
| 19:14:30 | sean-k-mooney | but you can also conenct via serial too | |
| 19:14:46 | sean-k-mooney | mikal: this alines with what i remember for what its worth | |
| 19:14:50 | sean-k-mooney | its entrily config driven | |
| 19:15:20 | mikal | I didn't think the domain XML could specify both VNC and SPICE, which I think is what that code you link to would do if you enabled both? | |
| 19:15:26 | sean-k-mooney | mikal: no i actully do expect ti to work because that work in libvirt | |
| 19:15:28 | mikal | There's no guard to have only one for a given instance? | |
| 19:15:56 | sean-k-mooney | mikal: im tryign to think if i currently have a debian devstack where i can check this | |
| 19:16:44 | mikal | I am slightly surprised that https://libvirt.org/formatdomain.html#graphical-framebuffers doesn't seem to actually mention any limits. | |
| 19:16:49 | mikal | Huh, maybe I am simply wrong. | |
| 19:19:31 | mikal | I can never tell from the oVirt docs what is a forward looking statement vs what got built, but oVirt appears to have supported this. https://www.ovirt.org/develop/release-management/features/virt/multiple-consoles.html | |
| 19:19:36 | mikal | So yeah, I think I am wrong. | |
| 19:20:33 | sean-k-mooney | to be clear they can enabel that in kolla-ansible without needign any changes to it via config overrieds | |
| 19:20:52 | sean-k-mooney | but it might be nicer not to have to do that | |
| 19:21:30 | mikal | Yeah, I am just going to remove my -1 from that review and bravely run away. I'll let someone else have an opinion on the best way to do things in ansible, that's not really my thing. | |
| 19:23:13 | sean-k-mooney | mikal: https://termbin.com/4c0u | |
| 19:23:39 | sean-k-mooney | so ya nova vm with vnc and spice booted on debian 13 (trixie) | |
| 19:24:19 | mikal | I am comfortable with being wrong here, and will now slink away to pretend none of this happened. | |
| 19:24:29 | mikal | Sorry for bothering you in your evening. | |
| 19:24:39 | sean-k-mooney | mikal: so this is somethign we dont test but can and proably should | |
| 19:24:49 | sean-k-mooney | but tis been a very very long time since i last did this | |
| 19:24:57 | sean-k-mooney | liek eailly 8 + years | |
| 19:25:20 | sean-k-mooney | mikal: dont be sorry | |
| 19:25:25 | sean-k-mooney | its good to know this still works | |
| 19:26:12 | mikal | Yeah, I need to think about it some more. I _could_ add CI for it on the Kerbside side, but its really outside of Kerbside's set of concerns, and I have other priorities like actually getting TLS working right in the Kolla-Ansible role so I can propose it upstream. So I will at it to my backlog and see where that takes me later. | |
| 19:26:24 | mikal | I have to run or I'll be late for work, talk more later. Thanks for your help. | |
| 19:26:34 | sean-k-mooney | we can just enabel it in the job that is currently testing spice | |
| 19:26:58 | sean-k-mooney | mikal: no worreis chat to soon o/ | |
| 19:53:26 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 20:23:07 | opendevreview | Merged openstack/nova master: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 20:23:20 | opendevreview | Merged openstack/nova master: Add handling for vTPM secret permission error https://review.opendev.org/c/openstack/nova/+/963648 | |
| 20:29:01 | opendevreview | Ghanshyam proposed openstack/nova master: Fix test_simple_tenant_usage test https://review.opendev.org/c/openstack/nova/+/966223 | |
| 20:31:01 | gmaan | zigo: this should fix the issue in test_simple_tenant_usage https://review.opendev.org/c/openstack/nova/+/966223 | |