| *** ykarel__ is now known as ykarel | 04:42 | |
| jssfr | dansmith, thanks for the review! | 05:34 |
|---|---|---|
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fixing the 500 HTTP code in the metadata service for incorrect queries https://review.opendev.org/c/openstack/nova/+/914249 | 06:02 |
| opendevreview | Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777 | 09:20 |
| *** bauzas0 is now known as bauzas | 10:43 | |
| *** mhen_ is now known as mhen | 10:44 | |
| opendevreview | Taketani Ryo proposed openstack/nova-specs master: Adjust the SEV/SEV-ES code for multiple cc support https://review.opendev.org/c/openstack/nova-specs/+/962578 | 10:52 |
| aravindh | hello folks, I see some specs for detaching boot cinder volumes from a VM, but most of them are abandoned. What is the offical stance on this feature? We had some usecase where we had to restore boot disks from snapshots. I want to understand what the current consenses about this feature in the community. | 10:58 |
| bauzas | dansmith: back to our discussion yesterday, I found the bug (this was in fill_metadata). I'll provide a functional test for testing the weigher in the fix change | 14:22 |
| bauzas | hopefully tomorrow given all the today meetings | 14:23 |
| dansmith | bauzas: you said that the fake instances had blank sysmeta in them, which will (intentionally) be skipped by fill_metadata | 14:23 |
| dansmith | that's not a bug, if that's what you're describing | 14:23 |
| bauzas | dansmith: https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L1608 there we need to pass the dict value | 14:25 |
| bauzas | ie.inst.system_metadata = utils.instance_sys_meta(updated[inst.uuid) | 14:25 |
| bauzas | anyway, working now on a functional test | 14:25 |
| dansmith | bauzas: um | 14:29 |
| dansmith | if that's wrong, seems like the image props weigher can't be working? | 14:30 |
| bauzas | yeah, that's why I'm creating a functional test | 14:31 |
| bauzas | we were only having tests that were checking that the weigher was running | 14:31 |
| bauzas | and we were having unittests for checking the results | 14:31 |
| dansmith | well, I was definitely testing that locally, but perhaps a refactor before merge broke it.. it was QAd downstream though, I'm pretty sure | 14:32 |
| bauzas | honestly, that's my fault here | 14:33 |
| bauzas | the whole one | 14:34 |
| bauzas | I was thinking this was simple to create a weigher but the fact is that this specific weigher needs to get some values not from the host state, and we didn't really tested it, just myself by testing once | 14:34 |
| dansmith | the unit test for fill_metadata uses the db and seems solid to me, but I'll wait for your patch | 14:36 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness https://review.opendev.org/c/openstack/placement/+/962596 | 15:06 |
| Uggla | Nova upstream meeting in ~30mn | 15:31 |
| bauzas | tic toc | 16:01 |
| Uggla | #startmeeting nova | 16:01 |
| opendevmeet | Meeting started Tue Sep 30 16:01:57 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| Uggla | Hello everyone | 16:02 |
| bauzas | \o | 16:02 |
| r-taketn | Hello | 16:02 |
| elodilles | o/ | 16:02 |
| tkajinam | o/ | 16:03 |
| Uggla | awaiting a couple of minutes, so people can join | 16:03 |
| Uggla | I know some of them are already in another meeting | 16:03 |
| gibi_ | o/ | 16:03 |
| Uggla | Let's start | 16:04 |
| Uggla | #topic Bugs (stuck/critical) | 16:04 |
| Uggla | #info No Critical bug | 16:04 |
| Uggla | #topic Gate status | 16:04 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| fwiesel | o/ | 16:04 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:04 |
| Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:05 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:05 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:05 |
| Uggla | #info I have seen (last week) "nova-tox-py312-threading fails intermittently" https://bugs.launchpad.net/nova/+bug/2125185 from gibi | 16:05 |
| Uggla | gibi is it something you want to discuss here or later in the eventlet part ? | 16:06 |
| gibi_ | I will recheck the fix there as it failed on the gate | 16:06 |
| gibi_ | 961781 | 16:06 |
| gibi_ | https://review.opendev.org/c/openstack/nova/+/961781 | 16:06 |
| gibi_ | my point here is just if you see nova-tox-py312-threading failing on your patch | 16:06 |
| gibi_ | but the other py312 job does not | 16:06 |
| gibi_ | then please let me know | 16:06 |
| Uggla | 👍 | 16:07 |
| gibi_ | I monitor the nova-tox-py312-threading job but I might miss things | 16:07 |
| gibi_ | that is it here | 16:07 |
| *** sambork_ is now known as sambork | 16:07 | |
| *** gibi_ is now known as gibi | 16:07 | |
| Uggla | Anything else to discuss about the gate ? I have not seen anything special but... ? | 16:07 |
| gibi | maybe one | 16:08 |
| gibi | if you see strange failures in nova-next regarding scheduling then let me no too :) nova-next uses threading mode for n-sch n-api n-metadata | 16:08 |
| gibi | /let me no/ let me know/ | 16:09 |
| gibi | I spotted some strange failurs there and even filed a bug | 16:09 |
| gibi | but I lost the link :) | 16:09 |
| gibi | https://bugs.launchpad.net/nova/+bug/2125598 | 16:10 |
| gibi | here it is | 16:10 |
| gibi | I need to get back to this and look deeper | 16:10 |
| gibi | that is it really for me now :) | 16:10 |
| Uggla | ok* | 16:11 |
| Uggla | Moving on to next topic skipping gmann's one due to PTO. | 16:11 |
| Uggla | #topic Release Planning | 16:11 |
| Uggla | #link https://releases.openstack.org/flamingo/schedule.html | 16:11 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:11 |
| Uggla | #info release in progress. | 16:11 |
| Uggla | #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg | 16:11 |
| Uggla | #info Please add the topics you would like to discuss in the above document. | 16:12 |
| Uggla | #info PTG meetings (to be confirmed) will happen room grizzly 15:00UTC -> 17:00UTC from Tuesday to Friday | 16:12 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness https://review.opendev.org/c/openstack/placement/+/962596 | 16:12 |
| Uggla | ^ I have booked the timeslots, but that could change. | 16:13 |
| tkajinam | maybe we need deadilines for G added to https://releases.openstack.org/gazpacho/schedule.html | 16:13 |
| bauzas | tkajinam: we usually discuss it at the PTG | 16:13 |
| tkajinam | ah, yes. ok | 16:14 |
| Uggla | tkajinam, this is something that will be added after PTG | 16:14 |
| bauzas | Uggla: fwiw, we could need to leave the Tuesday slots for cross-project discussions... or booking x-p topics into our own slots | 16:14 |
| bauzas | moderators should get proper information about x-p needs soon | 16:15 |
| Uggla | bauzas, yep sure. We will fine tune the schedule based on cross session projects and constraints. | 16:15 |
| Uggla | I guess for now the most important thing is to add topics to the etherpad. | 16:16 |
| Uggla | moving on | 16:16 |
| Uggla | #topic OpenAPI | 16:17 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:17 |
| Uggla | #info still 28 remaining atm. | 16:17 |
| Uggla | #topic Stable Branches | 16:17 |
| * Uggla giving the mic to elodilles | 16:17 | |
| elodilles | thanks o/ | 16:17 |
| elodilles | #info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state | 16:18 |
| elodilles | a couple of stable backports landed on old stable branches but we haven't merged anythin to stable/2025.2 yet, | 16:18 |
| elodilles | maybe the day after tomorrow, if the 2025.2 Flamingo release will be successful :) | 16:19 |
| elodilles | i think that's it from me about stable branches for now | 16:19 |
| Uggla | 🤞for thursday. | 16:19 |
| Uggla | thanks elodilles | 16:20 |
| elodilles | np | 16:20 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:20 |
| Uggla | fwiesel anything from you | 16:20 |
| fwiesel | Hi, sorry for the last time. I was on a company workshop. | 16:20 |
| Uggla | no worries | 16:21 |
| fwiesel | This week, I am working on fixing a problem in the pipeline. A Neutron update conflicts with our agent. | 16:21 |
| fwiesel | So, the agent won't even start up anymore. | 16:21 |
| fwiesel | I hope to fix that soon. | 16:21 |
| fwiesel | That's from my side. | 16:21 |
| fwiesel | Uggla: Back to you | 16:21 |
| Uggla | thx fwiesel | 16:22 |
| Uggla | #topic Gibi's news about eventlet removal. | 16:22 |
| * Uggla giving the mic to gibi | 16:22 | |
| gibi | o/ | 16:23 |
| gibi | #link Gazpacho plans are collected in the PTG etherpad: https://etherpad.opendev.org/p/nova-2026.1-ptg | 16:23 |
| gibi | #link We need a formal approval of the new BP: https://blueprints.launchpad.net/nova/+spec/eventlet-removal-gazpacho | 16:23 |
| gibi | #link We are going to restart our weekly eventlet sync every Wednesday 16:30 CEST, 14:30 UTC (during the summer) on meet.google.com/bcy-uqoz-hje | 16:23 |
| gibi | actually we restarted last week | 16:24 |
| sean-k-mooney | ack so the next wone is tomorow correct | 16:24 |
| gibi | next thing to land is nova-conductor https://review.opendev.org/c/openstack/nova/+/958575 please help me reviewing it | 16:24 |
| gibi | sean-k-mooney: yepp next one is tomorrow 14:30 UTC | 16:25 |
| gibi | that is all from me. Uggla lets try to approve the bp :) | 16:25 |
| Uggla | ok | 16:26 |
| gibi | is there any questions or objections against that bp? | 16:26 |
| sean-k-mooney | Uggla: one admin thing can you create teh 2026.1 seriese tomorrow and set it as the current devlopemnt cycle and upstea the 2025.2 serise and 2025.1 serose to reflect the current stable and supproted status reflecitvly | 16:27 |
| sean-k-mooney | i.e. once 2025.2 is offically released tomorow | 16:27 |
| sean-k-mooney | an no no objections to the blueprint form me :) | 16:28 |
| bauzas | sean-k-mooney: I'll help Uggla about how to do this for launchpad but sure | 16:28 |
| Uggla | sean-k-mooney you mean in launchpad right ? | 16:28 |
| sean-k-mooney | cool | 16:28 |
| sean-k-mooney | yep in launchpad | 16:28 |
| bauzas | and yeah, +1 on accepting the gazpacho eventlet bp as a specless one | 16:28 |
| sean-k-mooney | we will need to creat the serise in launchpadc before we can target theh bp to it | 16:29 |
| sean-k-mooney | that why i was bringin it up | 16:29 |
| Uggla | sean-k-mooney, sure as soon as F will be released, I'll update LP. | 16:29 |
| Uggla | #topic Open discussion | 16:30 |
| gibi | thanks folks | 16:30 |
| Uggla | (Uggla) I'm going to send a poll with new schedules proposal. | 16:30 |
| Uggla | for the upstream meetings. | 16:31 |
| Uggla | Last week I managed to collect some trends, so I can narrow a bit the choices. | 16:32 |
| Uggla | That's all 4 me. | 16:33 |
| Uggla | Does anyone whant to discuss about something ? | 16:33 |
| r-taketn | Uggla: I've just added one more topic to the agenda right before the meeting. Can I share it now? | 16:33 |
| Uggla | Sure, sorry I missed it because my mage was not refreshed. | 16:34 |
| Uggla | please go ahead r-taketn | 16:34 |
| r-taketn | Thank you | 16:34 |
| r-taketn | #link https://review.opendev.org/c/openstack/nova-specs/+/962578 | 16:34 |
| r-taketn | We proposed to adjust the existing SEV/SEV-ES code. | 16:34 |
| r-taketn | We think there is the need to generalize the existing SEV/SEV-ES code a bit to support other confidential computing features (e.g. Intel TDX, Arm CCA). | 16:35 |
| r-taketn | We would like to discuss the timing of this introduction. Specifically, we propose this as a standalone enhancement in advance to accept other features. Could we consider this approach? | 16:35 |
| gibi | I feel like this needs a spec and a PTG discussion and we need tkajinam present :) | 16:36 |
| sean-k-mooney | +1 to ^ | 16:37 |
| Uggla | gibi spec link above, but I agree to with ^ | 16:37 |
| tkajinam | :-) | 16:37 |
| sean-k-mooney | but the overall intent is to generalise teh code now so that it can be extended in teh future correct for more usecase and or vendors/plathforms | 16:37 |
| tkajinam | yeah like CCA and even TDX | 16:37 |
| r-taketn | sean-k-mooney: yes | 16:38 |
| sean-k-mooney | we have talked about TDX in the past as soemting that shoule eventually be supproted | 16:38 |
| Uggla | that sounds a reasonable "refactoring" | 16:38 |
| tkajinam | I'll check the spec and try to leave some feedback there for the discussion | 16:38 |
| gibi | Uggla: I blame the clock for not noticing the spec link :) | 16:38 |
| r-taketn | tkajinami: Thank you. | 16:39 |
| tkajinam | my quick suggestion at my first glance is that if you can put more focus on describing the expected problems of the current code, rather than how you update codes in details, that would help us understand the direction. | 16:39 |
| Uggla | I can say that my employer is interested in TDX and CCA support at some point. | 16:40 |
| Uggla | tkajinam +1 | 16:40 |
| sean-k-mooney | on thing i will say just glancing at it | 16:41 |
| sean-k-mooney | MemEncryptionConfig | 16:41 |
| r-taketn | tkajinami: Thank you for your feedbacks. I will clarify the purpose and merit to merge this refactoring in advance more. | 16:41 |
| sean-k-mooney | is currently a named touple or inhertied form it | 16:41 |
| sean-k-mooney | we may actully want to formmalise that inot a real class if we intend to build out more functionality with it | 16:41 |
| sean-k-mooney | i.e. have properties/functions assocated with it | 16:42 |
| sean-k-mooney | espcially if this woudl ever be inlcuded in any rpc object | 16:42 |
| sean-k-mooney | but we can reviw that as part of the spec | 16:42 |
| tkajinam | yeah | 16:43 |
| Uggla | sean-k-mooney +1, tuple is evil. :) | 16:43 |
| tkajinam | I'm guessing we may need to convert it to a class and create sub class per mechanisms. | 16:43 |
| sean-k-mooney | named tupples are less so but if we ever thing that class will be part fo an rpc call | 16:44 |
| sean-k-mooney | then it need to be an ovo | 16:44 |
| sean-k-mooney | ffor now its not so its fine so again lets look at that when we think about the generalisation | 16:44 |
| tkajinam | yeah | 16:44 |
| sean-k-mooney | it may not be relevent but nova.virt.hardware is used in the schdler and the computes already and maybe the conductor | 16:44 |
| sean-k-mooney | anyway i dont really ahve anythign else on that | 16:45 |
| r-taketn | Thank you for some feedbacks. My intent is the same to the above discussion(Specifically, MemEncryptionConfig) | 16:47 |
| r-taketn | Anyway, I need to write the spec in detail more. | 16:48 |
| r-taketn | I will improve the spec constantly. It would be helpful if we could discuss this at PTG or on Gerrit. | 16:49 |
| r-taketn | That's all from me today. thanks all. | 16:49 |
| gibi | sounds like a plan | 16:49 |
| Uggla | r-taketn 👍 | 16:50 |
| Uggla | Anything else to discuss. | 16:50 |
| gibi | - | 16:50 |
| tkajinam | nothing from me | 16:50 |
| bauzas | - | 16:52 |
| Uggla | #topic Bug scrubbing | 16:52 |
| Uggla | #info up to 186 (+9 from previous week :( ) | 16:52 |
| Uggla | ^ just providing the info that it increases a lot compare to last week. | 16:53 |
| Uggla | I know gibi is contributing to it. ;) | 16:53 |
| Uggla | I will try to look at them tomorrow, if I can answer/close some of them. | 16:54 |
| Uggla | Anyway I think that's all for today. | 16:54 |
| gibi | hey, I saw bugs, I open trackers :) | 16:55 |
| Uggla | Thank you for participating in this meeting. I’ll keep you posted if the next meeting is rescheduled. | 16:56 |
| Uggla | #endmeeting | 16:57 |
| opendevmeet | Meeting ended Tue Sep 30 16:57:12 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.log.html | 16:57 |
| r-taketn | Thank you | 16:57 |
| elodilles | thanks o/ | 16:57 |
| gibi | o/ | 16:58 |
| sean-k-mooney | Uggla: im triaging https://bugs.launchpad.net/nova/+bug/2125738 as low but its valid just an fyi | 16:58 |
| elodilles | Uggla: fyi, the nova ptg etherpad link is not updated on the ptg page: https://ptg.opendev.org/etherpads.html | 16:58 |
| opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron floating IPs https://review.opendev.org/c/openstack/nova/+/962604 | 16:59 |
| elodilles | Uggla: i think it can be updated via the openinfraptg bot in #openinfra-events channel | 16:59 |
| sean-k-mooney | its a fairly simpel fix in out bindep.txt to account for the package change | 16:59 |
| lajoskatona | Uggla: Hi, just a quick note that I slowly progress with the migration to SDK from neutronclient hell: https://review.opendev.org/q/topic:%22sdk_for_neutron%22 , after we are over the release week we can discuss how should it be consumed the easiest way :-) | 17:00 |
| sean-k-mooney | its not actully a bug requriing nova code change really beyond bindeps.txt to just document the relevent dep | 17:00 |
| sean-k-mooney | lajoskatona: ya you have broken it up that helps | 17:01 |
| sean-k-mooney | i likmed the orginal patch and saw you were updating it but i have not looked at it in any detial | 17:02 |
| sean-k-mooney | s/likmed/skimed/ | 17:02 |
| sean-k-mooney | lajoskatona: we have a related topic for the wtacher ptg about how/wen to start the convertion tothe sdk there. there is a depency on the neutron client in watcher too https://github.com/openstack/watcher/blob/master/requirements.txt#L38 | 17:04 |
| sean-k-mooney | but really not much of one today so i was sugesting we start with movaing the novaclinet and perhaps other over to the sdk next cycle | 17:05 |
| Uggla | sean-k-mooney, elodilles I will look at above later. | 17:06 |
| lajoskatona | sean-k-mooney: The thing that I run into and have to think about is that in n-client there are plenty of exotic exceptions like overquota and similar, but SDK has only basic exceptions like conflict | 17:09 |
| lajoskatona | at the moment I am not sure if using the simple conflict, notfound etc is enough or there is a need for cover the neutronclient exotic exceptions in SDK for example | 17:10 |
| sean-k-mooney | lajoskatona: ah so we may need to add some more detailed excption n nova for those diffent usecases to make the rest of the logic continue to work the same | 17:11 |
| sean-k-mooney | and your tryign to understand if that is the correct approch or if the nova code should be adapted to the geneirc expctions? | 17:12 |
| sean-k-mooney | it that the crux of the disucssion you want to have | 17:12 |
| sean-k-mooney | i.e. adtapt the generic excption to specific ones locally at the callsite or not? | 17:13 |
| sean-k-mooney | lajoskatona: for the most part as you have seen here https://review.opendev.org/c/openstack/nova/+/928022/12/nova/network/neutron.py#2933 we have tired to convert the neutron client excption into nova specific ones rather then propagate them outside ot the nova.network.neutron module | 17:16 |
| sean-k-mooney | so ideally code outside of nova/network/neutron.py shoudl not need to deal with sdk or neutron client excptions | 17:16 |
| sean-k-mooney | lajoskatona: alhtough i dont know if that is actully what you are asking | 17:17 |
| lajoskatona | sean-k-mooney: yes that is my problem now, I think the fresh patch for FIPs has some of these cases | 17:19 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#b2949 | 17:19 |
| sean-k-mooney | this is perhaps a good example | 17:19 |
| sean-k-mooney | before if it was not a client excption we loged the ecetpion and reaised | 17:19 |
| lajoskatona | or some real exotic ones: https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#3100 :-) | 17:20 |
| sean-k-mooney | we still proably shoudl actch other clent excptions and log them and then raise them again | 17:20 |
| sean-k-mooney | ah | 17:21 |
| sean-k-mooney | except (neutron_client_exc.IpAddressGenerationFailureClient, neutron_client_exc.ExternalIpAddressExhaustedClient | 17:21 |
| lajoskatona | SDK has general httpException, that can be used for such | 17:21 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: AMD SEV: omit iommu='on' for virtio devices https://review.opendev.org/c/openstack/nova/+/909635 | 17:22 |
| sean-k-mooney | so neutron_client_exc.OverQuotaClient apars ot be the oen that is missing | 17:22 |
| sean-k-mooney | right we are nologner rasign FloatingIpLimitExceeded | 17:22 |
| sean-k-mooney | so for partity we would need to disambiuage the sdk_exc.ConflictException | 17:23 |
| sean-k-mooney | and look at the message to know if its a quota issue or if we are out of ips | 17:23 |
| sean-k-mooney | i think in both case we would expect the allocation to fail and we would want to return a 409 | 17:25 |
| sean-k-mooney | so merging those together while it makes debuging hard does not seam to alter the api behavior | 17:25 |
| sean-k-mooney | lajoskatona: are you wonderign if nova shoudl do that disambiguation ro if it shoudl be in the sdk | 17:26 |
| sean-k-mooney | or are you wonderign if its required to treat them differently vs merging them into a singel expction | 17:27 |
| lajoskatona | sean-k-mooney: +1, I check it tomorrow to look inside the message | 17:27 |
| lajoskatona | sean-k-mooney: My first idea was to merge them | 17:27 |
| sean-k-mooney | i think as long as the end result at the api/externally does nto change i.e. 409 | 17:28 |
| sean-k-mooney | adn we have somethign reasonable in the debug logs | 17:28 |
| lajoskatona | sean-k-mooney: for tomorrow I will have more test results from zuul, so I will see if this aproach can work :-) | 17:28 |
| sean-k-mooney | so we can tell which it actully was its proably oke to merge them | 17:28 |
| sean-k-mooney | ack | 17:28 |
| sean-k-mooney | so for th ecase like this you could consider doing the merge in a seperate refactor first | 17:29 |
| sean-k-mooney | then the adopt sdk patch is just doing that | 17:29 |
| sean-k-mooney | i have not reviewd this in detail but in most cases i tlooks like you have found 1:1 mappings | 17:30 |
| sean-k-mooney | but sure let me know what you find after zuul reports | 17:30 |
| sean-k-mooney | lajoskatona: as an aside i think https://github.com/openstack/watcher/blob/master/watcher/common/nova_helper.py#L729-L744 is the only useage of neutronclient in watcher | 17:31 |
| sean-k-mooney | and i dont think we actully need that info really any more | 17:31 |
| sean-k-mooney | its part of the create_instance helper https://github.com/openstack/watcher/blob/master/watcher/common/nova_helper.py#L641 | 17:31 |
| sean-k-mooney | and that on my todolist to see fi we can entrily delete | 17:31 |
| sean-k-mooney | lajoskatona: so if nothing else im goign to see if we can remove the neutronclient dep entirly one way or another in 2026.1 | 17:32 |
| sean-k-mooney | watcher used ot have its onw impleation of evacuate/coldmigrate where it woudl snapshot a vm, delete it and create a new one | 17:34 |
| sean-k-mooney | i belive this is mostly dead code now | 17:34 |
| lajoskatona | sean-k-mooney: thanks I add watcher to my todolist, I have anyway some pending patches waiting for the release to not bother people (like in manila-ui) | 17:41 |
| melwitt | dansmith, bauzas: just some fyi, I have been realizing some issues while working on tempest tests for this series. I have added a few comments about it on the spec re-proposal here https://review.opendev.org/c/openstack/nova-specs/+/961564/1/specs/2026.1/approved/vtpm-live-migration.rst | 18:29 |
| melwitt | (about [libvirt]supported_tpm_secret_security valid values and overloading of the image_hw_tpm_secret_security instance sysmeta key) | 18:30 |
| dansmith | melwitt: I mostly gave up reviewing the spec re-proposal because it isn't easy to see the changes. So I've just been using the commit message to remind myself of the changes while looking at the code | 18:30 |
| dansmith | I figure it's better to spend my time on the code anyway | 18:30 |
| melwitt | dansmith: that's a reasonable approach, that was my thinking in enumerating the changes in the commit message. just saying I have noticed some things while doing tempest stuff and thought that might be the best place to note my findings | 18:31 |
| dansmith | ack | 18:32 |
| melwitt | it's all about the "opt in via resize" part of it. I have been writing tempest tests that do resize-confirm, resize-revert, and now I'm doing a rebuild-with-image-property one to see what happens | 18:33 |
| melwitt | I am unsure how comprehensive we will want to be with the ability for a user to change their TPM secret security policy | 18:34 |
| melwitt | dansmith: do you think that we should support a user _changing_ their secret security policy via a resize? or do you think the resize should be limited to legacy instances that don't have a policy set? because the former becomes a problem with us overloading the sysmeta key for it | 18:48 |
| melwitt | *the image property sysmeta key for it | 18:49 |
| sean-k-mooney | melwitt: interesting i had assumed the later that you would be able change via resize | 18:56 |
| melwitt | sean-k-mooney: you mean the former I think :) but yes I also went in with that assumption but I want to pause and make sure that's what we want, bc if we want that, I think we need to not use "image_hw_tpm_secret_security" as the key to stash in the instance sysmeta. bc it makes flavor/resize conflict errors | 18:57 |
| melwitt | (I have been finding things while adding more func tests and tempest tests) | 18:58 |
| melwitt | *flavor/image conflict errors | 18:59 |
| sean-k-mooney | well the flavor image conflcit check shoudl be checkign the glance image keys | 18:59 |
| sean-k-mooney | are we using the stashed copy | 18:59 |
| melwitt | , when the user may not have ever used an image prop | 18:59 |
| sean-k-mooney | i guess we might be to ensure that out of band glance changes dont creap in | 18:59 |
| sean-k-mooney | so we do not need ot use the same key | 19:00 |
| melwitt | we are yeah. for the check virt.hardware.get_tpm_secret_security_constraint() for example | 19:00 |
| sean-k-mooney | that was suggested just to minimise the number of places we have to check | 19:00 |
| melwitt | yeah. using the same key becomes a problem if the user never used an image with that key in it and we have set it internally for other reasons | 19:01 |
| sean-k-mooney | are you thinking we woudl add a new instance system metadata key ? | 19:01 |
| sean-k-mooney | or were you leanign to only allowing resize if its not a confilct | 19:01 |
| sean-k-mooney | meaning we shoudl not set it on update but treat it not being set as the old user policy | 19:01 |
| melwitt | if we want to be able to convert via resize, yes. like convert from host => deployment, etc. unless someone has a different idea | 19:01 |
| sean-k-mooney | i.e. defaulting in code instead of in the db | 19:01 |
| sean-k-mooney | if we dont use a new key then the simplest thing to do is treat key not in data as the USER policy | 19:02 |
| melwitt | because if we set image_hw_tpm_secret_security NOT from an image, it will get locked into the instance as if it had the image property, and it will reject any flavor hw:tpm_secret_security that does not agree with it | 19:02 |
| sean-k-mooney | then the key will only be set if it actully comes form the image | 19:03 |
| melwitt | everything currently works fine for legacy => host and legacy => deployment | 19:03 |
| melwitt | the problem comes when you have user => host, user => deployment, host => deployment, etc. new instances basically | 19:03 |
| sean-k-mooney | ya | 19:04 |
| melwitt | but yeah I see what you are saying | 19:04 |
| melwitt | that would work also | 19:04 |
| sean-k-mooney | basicly image_metadata.get("image_hw_tpm_secret_security", "user") in virt.hardware.get_tpm_secret_security_constraint() | 19:05 |
| sean-k-mooney | well | 19:05 |
| sean-k-mooney | hum | 19:05 |
| sean-k-mooney | htat does not quite work | 19:05 |
| sean-k-mooney | in the resize case we still need to know if its set or not set | 19:06 |
| sean-k-mooney | but for most other case it wil work | 19:06 |
| sean-k-mooney | i think you can still do it pretty cleanly | 19:08 |
| sean-k-mooney | but i dont know are we giving up anything else by doing it that way | 19:08 |
| melwitt | yeah. it's hard to know ahead of time | 19:08 |
| melwitt | what I'm doing now is writing up some more func tests and tempest tests to sort of demonstrate where the series is at the moment with regard to resize and rebuild behaviors | 19:09 |
| melwitt | I was thinking looking at those would make it easier to reason about how it's working at the moment and help us decide what to do next. at least it helps for me | 19:10 |
| sean-k-mooney | ya that sound like a good approch | 19:30 |
| sean-k-mooney | hum so this is the curretn defintion https://review.opendev.org/c/openstack/nova/+/942502/17/nova/virt/hardware.py | 19:33 |
| sean-k-mooney | and like the ohter get_*_constraint | 19:33 |
| sean-k-mooney | functions it only thake the flavor/image and does not know if it is a resize ectra | 19:34 |
| sean-k-mooney | so if we leave it as it it will work the way we want | 19:34 |
| sean-k-mooney | but it means we will need to do the defaulting diffently | 19:35 |
| sean-k-mooney | which isnot great | 19:35 |
| sean-k-mooney | melwitt: there is another option actully | 19:35 |
| sean-k-mooney | melwitt: instead of defaulting the value to "user" for the exiting vms | 19:36 |
| sean-k-mooney | we could defautl it to "legacy" | 19:36 |
| sean-k-mooney | which for all intents woudl be the same as user excpt it allows you to cange to a diffent policy | 19:36 |
| sean-k-mooney | in other words we would asdd a new value to the enum just for upgrades | 19:37 |
| sean-k-mooney | im not sure if that is a good idea or not but its an option to consider i guess | 19:37 |
| melwitt | sean-k-mooney: hm yeah I hadn't considered that | 19:45 |
| sean-k-mooney | we did somethign similar for pci neuma affinity. we added a "legacy" value for the old default when we added new policies | 19:45 |
| sean-k-mooney | we intened to eventually change the default but that never happened | 19:46 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias | 19:46 |
| melwitt | ah, good to know | 19:46 |
| sean-k-mooney | numa_policy | 19:46 |
| sean-k-mooney | Required NUMA affinity of device. Valid values are: legacy, preferred, required, and socket. | 19:46 |
| sean-k-mooney | i belive we intened to make preferred the default but we never got around to it | 19:47 |
| * sean-k-mooney ignores the fact that we really shoudl docuemnt what those mean in the doc.. | 19:47 | |
| melwitt | haha | 19:47 |
| sean-k-mooney | ok im wrapping for today, enjoy your evening | 19:48 |
| melwitt | ttyl o/ | 19:50 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!