Earlier  
Posted Nick Remark
#openstack-nova - 2025-09-30
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)
16:48:32 r-taketn Anyway, I need to write the spec in detail more.
16:49:33 r-taketn I will improve the spec constantly. It would be helpful if we could discuss this at PTG or on Gerrit.
16:49:52 r-taketn That's all from me today. thanks all.
16:49:52 gibi sounds like a plan
16:50:12 Uggla r-taketn 👍
16:50:30 Uggla Anything else to discuss.
16:50:37 gibi -
16:50:49 tkajinam nothing from me
16:52:07 bauzas -
16:52:48 Uggla #topic Bug scrubbing
16:52:56 Uggla #info up to 186 (+9 from previous week :( )
16:53:23 Uggla ^ just providing the info that it increases a lot compare to last week.

Earlier   Later