| opendevreview | Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304 | 05:41 |
|---|---|---|
| opendevreview | Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304 | 06:32 |
| mkuroha | bauzas: gibi: sean-k-mooney: I’ve updated the feature that copies the applied provider config files. I’d appreciate it if you could review it when you have time. https://review.opendev.org/c/openstack/nova/+/948304 | 09:01 |
| zigo | gmaan: Since you wrote these tests, any idea what could have gone wrong? https://bugs.launchpad.net/nova/+bug/2130703 | 09:23 |
| bauzas | mkuroha: as said in the change, pease reprovide the spec for 2026.1 so we could reapprove it | 10:00 |
| mkuroha | bauzas: I see, understood. I'll recreate it for the 2026.1 spec. | 10:09 |
| bauzas | mkuroha: thanks, ping me again once you're done, just copy the file and add in the history section something like "2025.2: Approved; 2026.1: Reproposed" | 10:10 |
| bauzas | should be quick | 10:10 |
| mkuroha | ok! thanks. | 10:14 |
| opendevreview | Masanori Kuroha proposed openstack/nova-specs master: Copy the spec approved in 2025.2 to 2026.1 https://review.opendev.org/c/openstack/nova-specs/+/966151 | 10:18 |
| mkuroha | bauzas: Thank you for the comment, I created: https://review.opendev.org/c/openstack/nova-specs/+/966151 | 10:20 |
| opendevreview | Merged openstack/nova master: api: Pre-query not deleted members in server groups https://review.opendev.org/c/openstack/nova/+/959696 | 11:14 |
| opendevreview | Merged openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | 11:15 |
| opendevreview | Merged openstack/nova stable/2025.1: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963845 | 11:40 |
| opendevreview | Merged openstack/nova stable/2025.1: Adds regression test for bug LP#2085135 https://review.opendev.org/c/openstack/nova/+/963846 | 11:40 |
| opendevreview | Merged openstack/nova stable/2025.1: Reset the mapped field of nodes at service deletion https://review.opendev.org/c/openstack/nova/+/963847 | 12:25 |
| sean-k-mooney | Zhan[m]: if you have input on https://review.opendev.org/c/openstack/nova/+/966106/comment/80b6a2a0_591c5cab/ feel free to add to it | 12:26 |
| sean-k-mooney | for context of others ^ is related to https://bugs.launchpad.net/nova/+bug/2128665 which is a very specific edgecase that results in live migration downtime when using calico | 12:27 |
| sean-k-mooney | it could impact other backend but shoudl not impact ml2/ovs or recent version fo ml2/ovn | 12:27 |
| sean-k-mooney | im conflcited on if this shoudl be fixed, if it should be fixed as a bug or as a feature to split post-live-migration into networking and the rest | 12:28 |
| opendevreview | Masanori Kuroha proposed openstack/nova-specs master: Copy the spec approved in 2025.2 to 2026.1 https://review.opendev.org/c/openstack/nova-specs/+/966151 | 12:52 |
| Zhan[m] | sean-k-mooney: Thanks, I will put comments there too. | 14:00 |
| Zhan[m] | Just for my own understanding, because we are not using ovn: from what you describe, the ovn driver in some sense is not really depending on the port binding activation but via the RARP packet (which I assume will be sent as soon as the destination QEMU process is resumed)? | 14:02 |
| Zhan[m] | calico is more of using the port binding activation as the trigger for switching the network to the dest QEMU so yes that's why we're hitting | 14:03 |
| sean-k-mooney | Zhan[m]: so the ml2/ovs ml2/linuxbrige (before they deleted it) and as of about a year ago ml2/ovn driver | 14:11 |
| sean-k-mooney | all wired up the port is there was a portbinidng for the host | 14:11 |
| sean-k-mooney | not just an active one | 14:11 |
| sean-k-mooney | for calico this si tricky because the tap does not exsit yet | 14:11 |
| sean-k-mooney | Zhan[m]: hoever we coudl modify the supprot for vif_type=tap to create the tap in pre-live-migrtion | 14:12 |
| sean-k-mooney | we are condiering doing that for ovn | 14:12 |
| sean-k-mooney | becuse ovn while it strcitly sepaking does not need it | 14:12 |
| sean-k-mooney | can take a long time to install the flow in larger clouds | 14:12 |
| sean-k-mooney | basically whith many vm and port the ovn db perfromcen cna resulting in reconsitaion taking over 30s in some cases | 14:13 |
| sean-k-mooney | Zhan[m]: we modifed ovn to allow the trafic swithc to be triggred by the RARP packet sent by qemu when the vm unpauses | 14:14 |
| sean-k-mooney | Zhan[m]: for ml2/ovs and ml2/linux bridge because they relyied on mac learning the RARP is the only thing that cause the traffic to be rerouted | 14:14 |
| sean-k-mooney | for calico that a bit harder becuase its an l3 backend so the mac learning frames are likely entirly ignored | 14:15 |
| sean-k-mooney | Zhan[m]: if you wanted to improve downtime mroe in calico then using the RARP to triger the update would be a consitent approch | 14:15 |
| Zhan[m] | Indeed it's tricky I think for l3 in general, thanks for the explanation. | 14:26 |
| Zhan[m] | but wondering if ml2/ovs can switch traffic with the RARP, what is the role that the port binding is playing here? | 14:27 |
| Zhan[m] | the way we use calico that i do see port bindings to the destination are created in pre live migraiton | 14:28 |
| opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2044235 https://review.opendev.org/c/openstack/nova/+/961602 | 14:29 |
| opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: nova-conductor puts instance in error state https://review.opendev.org/c/openstack/nova/+/961775 | 14:29 |
| opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: nova-conductor puts instance in error state https://review.opendev.org/c/openstack/nova/+/961775 | 14:34 |
| opendevreview | Henry Richter proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | 15:18 |
| opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | 15:29 |
| nicolairuckel | sean-k-mooney, thanks for your feedback. That fixed almost everything. | 15:40 |
| nicolairuckel | I was so sure I already tried that but maybe that was before you told me that I need to recreate the VM. | 15:41 |
| sean-k-mooney | cool ill pull in your updated code later in the week | 15:41 |
| nicolairuckel | thanks | 15:41 |
| sean-k-mooney | i tried the version i comment on but i didnt try removing the code i commened on | 15:41 |
| nicolairuckel | I also had to revert my changes to one of the tests because the XML changed. | 15:44 |
| nicolairuckel | That's fine, you shouldn't have to spend extra time on my mistakes. :D | 15:44 |
| sean-k-mooney | well this is part of doing code review | 15:45 |
| sean-k-mooney | makign sure we only change what needs to be changed | 15:45 |
| sean-k-mooney | so its fine i have that devstack set up so ill test it when i have time | 15:45 |
| sean-k-mooney | nicolairuckel: you left a coulpe of prints | 15:46 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/959682/9/nova/tests/functional/libvirt/test_uefi.py#61 | 15:46 |
| sean-k-mooney | that shoudl be removed | 15:46 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]nova-alt-configurations tests eventlet https://review.opendev.org/c/openstack/nova/+/965922 | 15:47 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Move monkey_patch from init to the entrypoints https://review.opendev.org/c/openstack/nova/+/965923 | 15:47 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Default native threading for sch, api and metadata https://review.opendev.org/c/openstack/nova/+/965924 | 15:47 |
| 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:48 |
| nicolairuckel | oh, right | 15:49 |
| nicolairuckel | thanks | 15:49 |
| opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | 15:50 |
| opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | 15:51 |
| gmaan | zigo: ack, I will check that | 16:02 |
| zigo | Cheers. | 16:02 |
| 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 |
| gibi | dansmith: sean-k-mooney: ^^ this (and its ancestors) are fixed up now based on the yesterday's dicussion | 16:46 |
| opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | 17:02 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Implement placement:same_subtree flavor extra spec https://review.opendev.org/c/openstack/nova/+/966205 | 17:19 |
| 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 | 17:32 |
| 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:00 |
| 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 |
| melwitt | in the flavor instead | 18:01 |
| melwitt | dansmith: what do you think? | 18: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 |
| dansmith | I hate to have to revise it again and do my testing again, but.. yeah | 18:12 |
| 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:13 |
| 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 |
| 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:14 |
| melwitt | but sys meta is not viewable in the scheduler request filter ... so I'm not sure how that could be | 18:16 |
| 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 |
| 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 |
| dansmith | s/not/potentially not/ | 18:19 |
| melwitt | yeah...thinking | 18:21 |
| * melwitt looks through the patches | 18:22 | |
| 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:23 |
| melwitt | for the object backleveling check | 18:24 |
| dansmith | right but you'll just do instance.flavor.get('security', 'user') above right? | 18:24 |
| dansmith | oh, well, | 18:24 |
| dansmith | you'll actually do something like: | 18:25 |
| dansmith | istpm = instance.flavor.get('tpm_model', None) | 18:25 |
| dansmith | if istpm: security = instance.flavor.get('security', None) else: security = None | 18:25 |
| dansmith | and then the rest will be the same right? | 18:25 |
| 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:28 |
| dansmith | if it has a model but no security, then it's user | 18:29 |
| dansmith | if it has a model and security, then $security | 18:29 |
| melwitt | whether it's a legacy vTPM instance vs a new defaulted 'user' vTPM instance | 18:29 |
| dansmith | if it has no model, then that's your None case, regardless of if it's new or old | 18:30 |
| melwitt | hm yeah, ok. | 18:30 |
| dansmith | I mean.. right? | 18:31 |
| 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:31 |
| melwitt | in my mind it was like, "if legacy, don't do anything different than it is today" | 18:32 |
| dansmith | no, legacy user and new user are the same AFAIK | 18:32 |
| 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 |
| 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:33 |
| * dansmith hasn't gotten that far in the series of course | 18:34 | |
| dansmith | but like if I want to delegate live migrate ability to project manager role or something that should work | 18:34 |
| melwitt | no, 'user' mimics legacy completely including not being live migratable | 18:34 |
| dansmith | or if the user doing the migration has been granted access to the key in barbican, it should work fine right? | 18:34 |
| melwitt | for 'host' yes | 18:35 |
| dansmith | okay I'm confused.. you're building in "user security is never migratable just because" behavior? | 18:35 |
| melwitt | but yeah, for 'user' LibvirtLiveMigrateData should never be in play | 18:35 |
| melwitt | that's what the spec intended anyway, 'user' just means legacy same-as-today behavior | 18:36 |
| melwitt | (i.e. live migrate rejected in the API) | 18:37 |
| dansmith | hrm | 18:37 |
| dansmith | I was assuming that user would be migratable if the key was accessible to the user doing the migration | 18:38 |
| melwitt | it could be, but the spec as far as I understood it left a mode for exact-same-as-today | 18:38 |
| 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:38 |
| melwitt | right | 18:39 |
| 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 |
| mikal | second opinion would be appreciated. | 19:08 |
| sean-k-mooney | mikal: so yes it can be on diffent host | 19:09 |
| sean-k-mooney | and also i think it did work a long long long time ago | 19:09 |
| sean-k-mooney | but i have no idea if it actully works today with the libvirt driver | 19:09 |
| sean-k-mooney | are they asseting that you can have both on the same host | 19:09 |
| sean-k-mooney | we have config option tha twoudl imply that and the console proxy coudl handel that | 19:10 |
| 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 |
| 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 |
| mikal | So yeah, I think they think they can mix on a single nova host, not say have different ones per cell. | 19:10 |
| sean-k-mooney | well its not even at the cell level | 19:11 |
| sean-k-mooney | it will work at the indigiual compute node level | 19:11 |
| sean-k-mooney | i can quickly check in devstack i guess | 19:11 |
| 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:13 |
| sean-k-mooney | mikal: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7825 | 19:14 |
| sean-k-mooney | so it is posibel in the code to have spice and vnc | 19:14 |
| sean-k-mooney | but you can also conenct via serial too | 19:14 |
| sean-k-mooney | mikal: this alines with what i remember for what its worth | 19:14 |
| sean-k-mooney | its entrily config driven | 19:14 |
| 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 |
| sean-k-mooney | mikal: no i actully do expect ti to work because that work in libvirt | 19:15 |
| mikal | There's no guard to have only one for a given instance? | 19:15 |
| sean-k-mooney | mikal: im tryign to think if i currently have a debian devstack where i can check this | 19:15 |
| mikal | I am slightly surprised that https://libvirt.org/formatdomain.html#graphical-framebuffers doesn't seem to actually mention any limits. | 19:16 |
| mikal | Huh, maybe I am simply wrong. | 19:16 |
| 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 |
| mikal | So yeah, I think I am wrong. | 19:19 |
| sean-k-mooney | to be clear they can enabel that in kolla-ansible without needign any changes to it via config overrieds | 19:20 |
| sean-k-mooney | but it might be nicer not to have to do that | 19:20 |
| 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:21 |
| sean-k-mooney | mikal: https://termbin.com/4c0u | 19:23 |
| sean-k-mooney | so ya nova vm with vnc and spice booted on debian 13 (trixie) | 19:23 |
| mikal | I am comfortable with being wrong here, and will now slink away to pretend none of this happened. | 19:24 |
| mikal | Sorry for bothering you in your evening. | 19:24 |
| sean-k-mooney | mikal: so this is somethign we dont test but can and proably should | 19:24 |
| sean-k-mooney | but tis been a very very long time since i last did this | 19:24 |
| sean-k-mooney | liek eailly 8 + years | 19:24 |
| sean-k-mooney | mikal: dont be sorry | 19:25 |
| sean-k-mooney | its good to know this still works | 19:25 |
| 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 |
| mikal | I have to run or I'll be late for work, talk more later. Thanks for your help. | 19:26 |
| sean-k-mooney | we can just enabel it in the job that is currently testing spice | 19:26 |
| sean-k-mooney | mikal: no worreis chat to soon o/ | 19:26 |
| opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | 19:53 |
| opendevreview | Merged openstack/nova master: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | 20:23 |
| opendevreview | Merged openstack/nova master: Add handling for vTPM secret permission error https://review.opendev.org/c/openstack/nova/+/963648 | 20:23 |
| opendevreview | Ghanshyam proposed openstack/nova master: Fix test_simple_tenant_usage test https://review.opendev.org/c/openstack/nova/+/966223 | 20:29 |
| gmaan | zigo: this should fix the issue in test_simple_tenant_usage https://review.opendev.org/c/openstack/nova/+/966223 | 20:31 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!