16:01:06 <bauzas> #startmeeting nova
16:01:06 <opendevmeet> Meeting started Tue Feb 18 16:01:06 2025 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <opendevmeet> The meeting name has been set to 'nova'
16:01:12 <bauzas> howdy folks
16:01:17 <fwiesel> o/
16:01:26 <r-taketn> o/
16:01:46 <bauzas> wiki again is super slow
16:02:00 <bauzas> I updated it in advance but the update failed
16:02:28 <elodilles> o/
16:02:57 <gibi> o/
16:03:03 <bauzas> yeah it failed
16:03:19 <elodilles> did my update interfere with yours? :-o
16:03:23 <bauzas> okay, lemme bring you my notes directly
16:03:31 <bauzas> Error: 1205 Lock wait timeout exceeded; try restarting transaction (dd34c169f1ba97e28fc00622156bd8b2e9de60ef.rackspaceclouddb.com)
16:03:39 <bauzas> that's what I get
16:03:44 <elodilles> hmmm
16:03:55 <bauzas> #topic Bugs (stuck/critical)
16:04:02 <bauzas> #info No critical bug
16:04:09 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:04:16 <bauzas> any bugs to raise ?
16:04:49 <bauzas> looks not, moving on
16:05:24 <bauzas> agenda for today will be https://paste.opendev.org/show/bHNrlGFsGF7V7TpuLwGY/
16:05:35 <bauzas> #topic Gate status
16:05:48 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:05:56 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:06:06 <bauzas> #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:06:31 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:07:03 <bauzas> #info Please try to provide meaningful comment when you recheck
16:07:10 <bauzas> that's it for gate
16:07:50 <bauzas> anything to talk about our gate ?
16:08:04 <bauzas> fwiw, I was more present upstream these days and found no real problem
16:08:38 <bauzas> moving on
16:08:42 <bauzas> #topic Release Planning
16:08:48 <bauzas> #link https://releases.openstack.org/epoxy/schedule.html
16:09:15 <bauzas> #info Nova deadlines are set in the above schedule
16:09:22 <bauzas> #info 1.5 week before Feature Freeze
16:09:29 <Uggla> o/
16:09:30 <bauzas> the bell is ticking
16:09:38 <bauzas> #topic Review priorities
16:09:54 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.1-status
16:10:02 <bauzas> I eventually updated this etherpad \o/
16:10:15 <bauzas> and I've started to do a round of reviews
16:11:51 <bauzas> anything we should discuss ?
16:12:09 <bauzas> if not, moving on in a sec
16:13:13 <bauzas> #topic PTG planning
16:13:19 <bauzas> as a reminder,
16:13:22 <bauzas> #info Next PTG will be held on Apr 7-11
16:13:29 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.2-ptg
16:13:44 <bauzas> please add your items to discuss at that PTG into that etherpad
16:14:45 <bauzas> #topic Stable Branches
16:14:54 <bauzas> elodilles: take the mic
16:14:59 <elodilles> yepp
16:15:03 <elodilles> #info stable gates seem to be healthy
16:15:14 <elodilles> #info stable/2023.2 release patch: https://review.opendev.org/c/openstack/releases/+/941420 (stable/2023.2 (bobcat) is going to transition to EOL in ~2 months)
16:15:35 <elodilles> note that it will directly go to End of Life as it is not a SLURP release
16:15:48 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:15:56 <elodilles> and that's all from me
16:18:20 <fwiesel> I suspect it is my turn.
16:18:21 <fwiesel> #topic vmwareapi 3rd-party CI efforts Highlights
16:18:29 <fwiesel> No updates from my side.
16:18:29 <bauzas> thanks fwiesel
16:18:34 <bauzas> cool thanks
16:18:45 <bauzas> still fighting the dragons ?
16:19:25 <fwiesel> Yes, I didn't quite get around to it, that is the main reason of the lack of progress.
16:19:36 <bauzas> no worries, we all have urgent business to sell
16:19:42 <bauzas> moving on then
16:19:53 <bauzas> #topic Open discussion
16:20:00 <bauzas> two items today AFAICS
16:20:07 <bauzas> (sean-k-mooney) neutron removal of linux bridge
16:20:09 <bauzas> sean-k-mooney: around N?
16:20:14 <sean-k-mooney> yep
16:20:28 <sean-k-mooney> so... neutron removed linxu bridge
16:20:38 <sean-k-mooney> they did not deprecated it in the last slurp
16:20:42 <sean-k-mooney> so we never did
16:20:55 <sean-k-mooney> so my propsoal is we deprecate it this release
16:21:03 <sean-k-mooney> disable the linux bridge job
16:21:09 <sean-k-mooney> and remove supprot next cycle
16:21:14 <sean-k-mooney> we need to do this in os-vif as well
16:21:18 <sean-k-mooney> i have a patch up for that
16:21:33 <sean-k-mooney> os-vif is subject to the non clinet lib freeze and is currently blocked
16:21:37 <sean-k-mooney> form merging code because of this
16:21:47 <sean-k-mooney> we have some patches we want to merge before then
16:21:55 <sean-k-mooney> so the topci is, are we ok with that plan
16:22:01 <sean-k-mooney> deprecate and disbales testing this cycle
16:22:16 <sean-k-mooney> then remove next cycle
16:22:23 <gibi> I'm OK to deprecate and disable. We cannot really do anything else if neutron pulled the plug
16:22:44 <sean-k-mooney> ill submit the patch for that for nova later today
16:22:48 <sean-k-mooney> i jsut need to write it
16:23:05 <bauzas> yeah I think we can agree
16:23:19 <sean-k-mooney> we are not fully blocked as the linux bridge job only tirggers on a subset of files
16:23:24 <bauzas> send the deprecation signal and remove the job
16:24:18 <bauzas> anyone having concerns by the deprecation ?
16:25:02 <sean-k-mooney> nova in 2025.1 woudl be able to run with older neutron or with linux bridge if you wrote an out of tree ml2/driver
16:25:13 <sean-k-mooney> so i will note that in the release note
16:25:47 <sean-k-mooney> but i dont expect that we will need/want to supprot that going forward. we can have that discssion before doing the removal form nova itslef
16:26:12 <sean-k-mooney> the thing is os-vif does nto host plugins for out of tree neutron backends
16:26:25 <sean-k-mooney> so we shoudl remove the os-vif supprot in os-vif next cycle in either case
16:26:42 <sean-k-mooney> anyway thats all form me
16:27:38 <bauzas> cool thanks
16:28:14 <bauzas> #agreed linuxbridge will be deprecated by 2025.1
16:28:30 <bauzas> next time
16:28:37 <bauzas> gmann (I will not be able to attend the meeting due to a time conflict, but most of you know the context and proposal), Spec freeze exception for RBAC service/manager role
16:28:48 <bauzas> #link  https://review.opendev.org/c/openstack/nova-specs/+/937650
16:29:43 <bauzas> gmann requested for a late specless approval
16:29:53 <bauzas> spec approval (my bad)
16:30:01 <bauzas> Spec has one +2 already and code changes are in progress: https://review.opendev.org/q/topic:%22bp/policy-service-and-manager-role-default%22
16:30:47 <bauzas> usually we would not approve a spec so late in the cycle, but there are some criterias here to talk
16:31:01 <bauzas> 1/ the spec is quite simple and only relates to policy changes
16:31:37 <bauzas> 2/ we already merged some efforts related to policy
16:31:50 <bauzas> 3/ sean-k-mooney already accepted the spec
16:32:00 <bauzas> would there any concern by the approval ?
16:32:34 <sean-k-mooney> yes, although that was with the coment it needs an execption and the undersanding we woudl have this converstaion about 4 weeks ago
16:32:52 <sean-k-mooney> from me just review bandwith
16:32:58 <bauzas> my personal opinion on that is the risk about the policy changes
16:33:19 <gibi> yeah, if there are two cores signing up for reviewing it the I have no objection
16:33:26 <gibi> but the time is pretty sort
16:33:28 <bauzas> we're talking of modifying the inter-service communication
16:33:37 <sean-k-mooney> we are but
16:33:46 <bauzas> so the patches would require extra caution
16:33:59 <sean-k-mooney> by defualt i this cycle swe will go form admin to admin or service
16:34:07 <bauzas> I'm not opposed to give that series a late approval, but I wouldn't rush on reviewing the patches to be clear
16:34:17 <sean-k-mooney> so the real upgrade impact woudl be next cycle or whenever we drop admin
16:34:27 <sean-k-mooney> the manager changes would also be additive
16:35:32 <sean-k-mooney> we obviouly need to validate that our exsing jobs do not require modfiigcaiont to pass
16:35:40 <sean-k-mooney> to ensure there is no upgrade impact
16:36:06 <sean-k-mooney> we may also want to explcity have the new defautl job enable extra testing fo the manager policy
16:36:43 <sean-k-mooney> gmann: what the state of the tempets testing for this
16:39:04 <sean-k-mooney> my irc client freeked out so not sure if i missed messages
16:40:20 <bauzas> sean-k-mooney: gmann was unable to attend the meeting
16:40:28 <bauzas> so he won't be able to reply to you I guess
16:40:31 <sean-k-mooney> oh ok.
16:40:54 <bauzas> fwiw, I don't really know what to do with that spec
16:41:07 <bauzas> I don't have the context yet and I need some time to reload it
16:41:14 <bauzas> so I won't be able to +2 it shortly
16:41:49 <sean-k-mooney> lookign at the tempest patches
16:42:01 <bauzas> if any other nova-core is able to review that spec, I'm not opposed to a late approval but those two cores shall honestly sign off for the implementation review too
16:42:38 <sean-k-mooney> so i am not sure ill have time to rewview it either by the way
16:42:55 <sean-k-mooney> i think this shoudl be moved to next cycle honestly
16:43:50 <sean-k-mooney> i woudl prefer to focus on merging the ohter approved specs
16:45:00 <gibi> I dont see cores signing up, so punt it
16:45:13 <bauzas> that's sad but reasonable
16:45:22 <bauzas> we shouldn't offer help if we can't review the patches
16:45:58 <sean-k-mooney> to be clear form my perspecitve this was punted when it missed the sepc freeze
16:46:12 <sean-k-mooney> and it was not approved as an exption in the team meeting after
16:46:36 <bauzas> #agreed unfortunately given the review bandwidth and the time it takes to gather context for approving the spec, we can't late approve the spec as we can't also guarantee that we could review the implementation patches in the reasonable timeline that we have
16:47:52 <bauzas> okay, that was it for today's items in the agenda
16:47:55 <bauzas> anything anyone ?
16:47:57 <r-taketn> bauzas: I have one request. (My entry might have been deleted, Sorry for the confusion)
16:48:35 <MengyangZhang[m]> I also have a topic. https://blueprints.launchpad.net/nova/+spec/enhanced-granularity-and-live-application-of-qos Would like to hear how the community feels about this before moving on looking into the code and writing a spec. Already proposed this idea to cinder and they liked the idea of per-project control of qos and live updating the qos limits.
16:49:32 <r-taketn> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/244U52T3HINVWUFSMPMA45A67BUPAQGK/
16:50:35 <sean-k-mooney> MengyangZhang[m]: we will not provide a inteface to modify cpu qos via cidner forntend qos
16:50:44 <bauzas> r-taketn: ok, you're the next
16:50:45 <sean-k-mooney> so if thaty what you plandded -2
16:50:59 <sean-k-mooney> but ya lest discuss r-taketn topic first
16:51:08 <r-taketn> Could you please check the last message the above mailing list and give your comments?
16:51:25 <sean-k-mooney> r-taketn: sure but just to clarify somethign we said previous
16:51:35 <sean-k-mooney> nova will not merge any code for unreleased hardware
16:51:44 <bauzas> r-taketn: oh, OK, that's a follow-up question on Arm-CCA
16:52:12 <bauzas> yeah, what sean-k-mooney said
16:52:32 <bauzas> we can't just support something that our operators can't use
16:53:09 <r-taketn> Oh, ok. I might misunderstand
16:53:19 <sean-k-mooney> if there are some feautres that will eventually be used by CCA but are useful on there own we can enabel that in advance
16:54:43 <bauzas> for the sake of the meeting time, could we then move to the second item ?
16:55:13 <r-taketn> yes
16:55:54 <bauzas> thanks
16:56:03 <bauzas> MengyangZhang[m]: looking at your blueprint
16:56:07 <sean-k-mooney> MengyangZhang[m]: to be clear "live QoS updates to CPU and memory limits, including configurations in cputune, cachetune, and memorytune libvirt XML elements to enable seamless performance adjustments for running instances." is not something we can or shoudl supprot via cidner frontend qos policies
16:56:34 <sean-k-mooney> if we wanted to do that we woudl need to add a new QOS api to nova to allows admins to defien qos polices
16:56:43 <sean-k-mooney> and a instance action to apply it
16:56:45 <bauzas> that sounds a very large topic to discuss
16:57:03 <bauzas> haven't we already proposed to discuss those kind of topics at the PTG ?
16:57:16 <sean-k-mooney> i tought so
16:57:22 <MengyangZhang[m]> <sean-k-mooney> "Mengyang Zhang: we will not..." <- It's not via cinder qos. What we want to achieve is to be able to live update all QoS limits on existing VMs on nova side. For disk qos, it's a bit special as it requires cinder side changes.
16:57:40 <bauzas> I actually see it in https://etherpad.opendev.org/p/nova-2025.2-ptg#L47
16:57:51 <bauzas> so I'd recommend to defer the discussion at the PTG
16:57:55 <sean-k-mooney> MengyangZhang[m]: so the only qos you can configure today in nova
16:58:00 <sean-k-mooney> is via flavor extra specs
16:58:14 <sean-k-mooney> so what you are effectivly asking for is a limited form of live resize
16:59:33 <MengyangZhang[m]> we can set cpu and memory qos via flavor extra specs. But cinder is a bit different.
17:00:14 <sean-k-mooney> you can set disk qos via flavor extra specs too.
17:00:49 <bauzas> we're over time
17:00:50 <sean-k-mooney> cidner qos today coudl be supproted via swap voluem (volume retype in cinder)
17:00:57 <bauzas> thanks folks
17:01:10 <bauzas> I'll end the meeting but I also recommend talking about that usecase at the PTG
17:01:12 <bauzas> thnaks
17:01:15 <bauzas> #endmeeting