Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-11-05
15:48:07 sean-k-mooney nicolairuckel: im on a call so cant review realtime but skiming over it that was the only thing that imidatly jumped out to me
15:49:36 nicolairuckel oh, right
15:49:37 nicolairuckel thanks
15:50:14 opendevreview Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682
15:51:32 opendevreview Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682
16:02:07 gmaan zigo: ack, I will check that
16:02:23 zigo Cheers.
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 flavor instead
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: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.

Earlier   Later