| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 16:14:02 | tkajinam | ah, yes. ok | |
| 16:14:03 | Uggla | tkajinam, this is something that will be added after PTG | |
| 16:14:41 | 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:15:08 | bauzas | moderators should get proper information about x-p needs soon | |
| 16:15:36 | Uggla | bauzas, yep sure. We will fine tune the schedule based on cross session projects and constraints. | |
| 16:16:20 | Uggla | I guess for now the most important thing is to add topics to the etherpad. | |
| 16:16:59 | Uggla | moving on | |
| 16:17:06 | Uggla | #topic OpenAPI | |
| 16:17:13 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:17:21 | Uggla | #info still 28 remaining atm. | |
| 16:17:45 | Uggla | #topic Stable Branches | |
| 16:17:59 | elodilles | thanks o/ | |
| 16:18:05 | elodilles | #info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state | |
| 16:18:41 | elodilles | a couple of stable backports landed on old stable branches but we haven't merged anythin to stable/2025.2 yet, | |
| 16:19:04 | elodilles | maybe the day after tomorrow, if the 2025.2 Flamingo release will be successful :) | |
| 16:19:19 | elodilles | i think that's it from me about stable branches for now | |
| 16:19:44 | Uggla | 🤞for thursday. | |
| 16:20:00 | Uggla | thanks elodilles | |
| 16:20:05 | elodilles | np | |
| 16:20:31 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:20:42 | Uggla | fwiesel anything from you | |
| 16:20:45 | fwiesel | Hi, sorry for the last time. I was on a company workshop. | |
| 16:21:13 | Uggla | no worries | |
| 16:21:14 | fwiesel | This week, I am working on fixing a problem in the pipeline. A Neutron update conflicts with our agent. | |
| 16:21:24 | fwiesel | So, the agent won't even start up anymore. | |
| 16:21:30 | fwiesel | I hope to fix that soon. | |
| 16:21:34 | fwiesel | That's from my side. | |
| 16:21:47 | fwiesel | Uggla: Back to you | |
| 16:22:29 | Uggla | thx fwiesel | |
| 16:22:42 | Uggla | #topic Gibi's news about eventlet removal. | |
| 16:23:21 | gibi | o/ | |
| 16:23:36 | gibi | #link Gazpacho plans are collected in the PTG etherpad: https://etherpad.opendev.org/p/nova-2026.1-ptg | |
| 16:23:43 | gibi | #link We need a formal approval of the new BP: https://blueprints.launchpad.net/nova/+spec/eventlet-removal-gazpacho | |
| 16:23:59 | 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:24:05 | gibi | actually we restarted last week | |
| 16:24:46 | sean-k-mooney | ack so the next wone is tomorow correct | |
| 16:24:50 | gibi | next thing to land is nova-conductor https://review.opendev.org/c/openstack/nova/+/958575 please help me reviewing it | |
| 16:25:03 | gibi | sean-k-mooney: yepp next one is tomorrow 14:30 UTC | |
| 16:25:55 | gibi | that is all from me. Uggla lets try to approve the bp :) | |
| 16:26:38 | Uggla | ok | |
| 16:26:55 | gibi | is there any questions or objections against that bp? | |
| 16:27:36 | 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:47 | sean-k-mooney | i.e. once 2025.2 is offically released tomorow | |
| 16:28:03 | sean-k-mooney | an no no objections to the blueprint form me :) | |
| 16:28:17 | bauzas | sean-k-mooney: I'll help Uggla about how to do this for launchpad but sure | |
| 16:28:26 | Uggla | sean-k-mooney you mean in launchpad right ? | |
| 16:28:27 | sean-k-mooney | cool | |
| 16:28:32 | sean-k-mooney | yep in launchpad | |
| 16:28:46 | bauzas | and yeah, +1 on accepting the gazpacho eventlet bp as a specless one | |
| 16:29:04 | sean-k-mooney | we will need to creat the serise in launchpadc before we can target theh bp to it | |
| 16:29:11 | sean-k-mooney | that why i was bringin it up | |
| 16:29:13 | Uggla | sean-k-mooney, sure as soon as F will be released, I'll update LP. | |
| 16:30:05 | Uggla | #topic Open discussion | |
| 16:30:47 | gibi | thanks folks | |
| 16:30:48 | Uggla | (Uggla) I'm going to send a poll with new schedules proposal. | |
| 16:31:14 | Uggla | for the upstream meetings. | |
| 16:32:16 | Uggla | Last week I managed to collect some trends, so I can narrow a bit the choices. | |
| 16:33:06 | Uggla | That's all 4 me. | |
| 16:33:42 | Uggla | Does anyone whant to discuss about something ? | |
| 16:33:46 | r-taketn | Uggla: I've just added one more topic to the agenda right before the meeting. Can I share it now? | |
| 16:34:23 | Uggla | Sure, sorry I missed it because my mage was not refreshed. | |
| 16:34:31 | Uggla | please go ahead r-taketn | |
| 16:34:33 | r-taketn | Thank you | |
| 16:34:41 | r-taketn | #link https://review.opendev.org/c/openstack/nova-specs/+/962578 | |
| 16:34:51 | r-taketn | We proposed to adjust the existing SEV/SEV-ES code. | |
| 16:35:03 | 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:29 | 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:36:41 | gibi | I feel like this needs a spec and a PTG discussion and we need tkajinam present :) | |
| 16:37:11 | sean-k-mooney | +1 to ^ | |
| 16:37:22 | Uggla | gibi spec link above, but I agree to with ^ | |
| 16:37:34 | tkajinam | :-) | |
| 16:37: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:56 | tkajinam | yeah like CCA and even TDX | |
| 16:38:06 | r-taketn | sean-k-mooney: yes | |
| 16:38:16 | sean-k-mooney | we have talked about TDX in the past as soemting that shoule eventually be supproted | |
| 16:38:31 | Uggla | that sounds a reasonable "refactoring" | |
| 16:38:45 | tkajinam | I'll check the spec and try to leave some feedback there for the discussion | |
| 16:38:56 | gibi | Uggla: I blame the clock for not noticing the spec link :) | |
| 16:39:08 | r-taketn | tkajinami: Thank you. | |
| 16:39:44 | 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:40:07 | Uggla | I can say that my employer is interested in TDX and CCA support at some point. | |
| 16:40:50 | Uggla | tkajinam +1 | |
| 16:41:21 | sean-k-mooney | on thing i will say just glancing at it | |
| 16:41:23 | sean-k-mooney | MemEncryptionConfig | |
| 16:41:25 | r-taketn | tkajinami: Thank you for your feedbacks. I will clarify the purpose and merit to merge this refactoring in advance more. | |
| 16:41:37 | sean-k-mooney | is currently a named touple or inhertied form it | |
| 16:41:55 | 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:42:04 | sean-k-mooney | i.e. have properties/functions assocated with it | |
| 16:42:33 | sean-k-mooney | espcially if this woudl ever be inlcuded in any rpc object | |
| 16:42:47 | sean-k-mooney | but we can reviw that as part of the spec | |
| 16:43:23 | tkajinam | yeah | |
| 16:43:39 | Uggla | sean-k-mooney +1, tuple is evil. :) | |
| 16:43:54 | tkajinam | I'm guessing we may need to convert it to a class and create sub class per mechanisms. | |
| 16:44:02 | sean-k-mooney | named tupples are less so but if we ever thing that class will be part fo an rpc call | |
| 16:44:07 | sean-k-mooney | then it need to be an ovo | |
| 16:44:29 | sean-k-mooney | ffor now its not so its fine so again lets look at that when we think about the generalisation | |
| 16:44:39 | tkajinam | yeah | |
| 16:44:59 | 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:45:21 | sean-k-mooney | anyway i dont really ahve anythign else on that | |
| 16:47:42 | r-taketn | Thank you for some feedbacks. My intent is the same to the above discussion(Specifically, MemEncryptionConfig) | |