16:00:34 <bauzas> #startmeeting nova
16:00:34 <opendevmeet> Meeting started Tue Jan 21 16:00:34 2025 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:34 <opendevmeet> The meeting name has been set to 'nova'
16:00:37 <bauzas> hey folks
16:00:37 <gibi> elodilles: don't worry :)
16:00:47 <elodilles> :)
16:00:48 <elodilles> o/
16:00:55 <fwiesel> o/
16:00:56 <masahito> o/
16:01:05 <opendevreview> Merged openstack/placement stable/2024.2: Factor out allocation candidate generation strategy  https://review.opendev.org/c/openstack/placement/+/938940
16:01:07 <opendevreview> Merged openstack/placement stable/2024.2: Add round-robin candidate generation strategy  https://review.opendev.org/c/openstack/placement/+/938941
16:01:17 <gibi> elodilles: this is just figthing with devstack to configure placement to use the new config options in nova-next
16:01:41 <elodilles> gibi: ACK (merged meanwhile ^^^)
16:01:47 <gibi> elodilles: thanks
16:01:58 <bauzas> okay let's start the meeting
16:02:23 <bauzas> I'll be clear, packed day with meetings, so I had no time to update the agenda
16:02:28 <bauzas> so let's do it live
16:02:46 <bauzas> #topic Bugs (stuck/critical)
16:02:55 <bauzas> #info No Critical bug
16:03:00 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:06 <bauzas> anything about bugs ?
16:03:42 <Uggla> o/
16:03:45 <bauzas> looks not
16:03:56 <bauzas> #topic Gate status
16:04:02 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:07 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:04:14 <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:04:20 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:04:26 <bauzas> #info Please try to provide meaningful comment when you recheck
16:04:41 <bauzas> (still waiting for the periodic runs check to be done)
16:04:58 <bauzas> anything about the gate ?
16:05:20 <bauzas> I'll be honest, this week I was mostly away from upstream CI
16:05:40 <bauzas> okay, all periodics are green-ish (one is on RETRY)
16:05:58 <bauzas> I guess we can move on
16:06:52 <bauzas> then, let's move on
16:07:06 <bauzas> #topic Release Planning
16:07:11 <bauzas> #link https://releases.openstack.org/epoxy/schedule.html
16:07:17 <bauzas> #info Nova deadlines are set in the above schedule
16:07:25 <bauzas> #info 5 weeks before Feature Freeze
16:07:28 <bauzas> tick tock...
16:07:55 <bauzas> as a reminder from last week :
16:08:06 <bauzas> #info we'll try to create as os-traits release next 2 week, please provide your os-traits patches sooner than later.
16:08:33 <bauzas> we already merged one trait proposal, so feel free to propose the ones you need for your series
16:08:40 <bauzas> #undo
16:08:40 <opendevmeet> Removing item from minutes: #info we'll try to create as os-traits release next 2 week, please provide your os-traits patches sooner than later.
16:08:49 <bauzas> #info we'll try to create as os-traits release next week, please provide your os-traits patches sooner than later.
16:08:57 <bauzas> (bad copy paste)
16:09:03 <bauzas> this is said
16:09:05 <bauzas> any question ?
16:09:48 <Uggla> We need to bump the LIBVIRT / QEMU version too.
16:10:12 <bauzas> we'll discuss that in the open discussion section
16:10:22 <Uggla> ok
16:10:28 <bauzas> moving on then
16:10:31 <bauzas> #topic Review priorities
16:10:39 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.1-status
16:11:01 <bauzas> hemanth: I've seen your review request on  https://review.opendev.org/c/openstack/nova/+/939044
16:11:15 <bauzas> I'll make sure that your patch is in the above etherpad
16:11:50 <bauzas> oh it's there already
16:12:59 <bauzas> hemanth: given the patch, we'll discuss that in the open discussion section to see whether it's a specless blueprint or not and whether we can accept it as an feature exception for this cycle
16:13:20 <bauzas> moving on then
16:13:23 <bauzas> #topic Stable Branches
16:13:32 <bauzas> elodilles: your time :)
16:13:39 <elodilles> ACK
16:13:44 <elodilles> i should be quick:
16:13:48 <elodilles> #info nothing to report, stable gates seem to be healthy
16:13:54 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:14:04 <elodilles> this is all
16:14:07 <elodilles> from me
16:14:39 <bauzas> ++
16:14:47 <bauzas> thanks
16:14:53 <elodilles> np
16:14:55 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:15:01 <bauzas> fwiesel: anything to mention ?
16:15:13 <fwiesel> Nothing to report from my side
16:15:26 <bauzas> cool
16:15:33 <bauzas> #topic Open discussion
16:15:44 <bauzas> pretty large agenda for today
16:15:49 <bauzas> let's be productive
16:15:57 <bauzas> (sean-k-mooney) disable the heal instance info cache periodic
16:16:00 <bauzas> around ?
16:16:35 <bauzas> if not, we can leave that item for next week, no worries
16:16:47 <bauzas> next item
16:16:56 <bauzas> (bauzas) Updating our QEMU/libvirt min versions ?
16:17:26 <bauzas> so, when working with Uggla on the VFIO-pci series for live-migration, we discussed about the minimum versions we have
16:18:06 <bauzas> the context is that in libvirt we do support our minimums from Focal, AFAICT :)
16:18:56 <bauzas> but now, our tested runtimes are clear, we only need to support Jammy
16:19:00 <bauzas> #link https://governance.openstack.org/tc/reference/runtimes/2025.1.html
16:19:51 <bauzas> during the Caracal PTG, we agreed on upgrading our min versions as soon as we were able to bump them, and I'd prefer honestly to bump our mins on that SLURP release rather than on a non-SLURP
16:20:25 <gibi> +1
16:20:28 <bauzas> (which would mean that we need to forward-port the relnotes to G* which would be the next SLURP if we bump during Flamingo)
16:20:28 <Uggla> +1
16:20:51 <bauzas> are we okay to bump our mins to be the existing the next mins ?
16:20:57 <bauzas> which are Jammy ones
16:21:20 <bauzas> we could define the next mins to be the Noble versions for QEMU and libvirt
16:21:55 <gibi> +1 on making the current next_min our new min, and set next_min to whatever in Noble
16:21:58 <bauzas> #link https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L215-L224
16:22:24 * gibi does not feel the quorum
16:22:38 <Uggla> sounds good, are there docs to update too ?
16:22:39 <bauzas> that's OK, we can provide a patch and people will review it anyway
16:23:05 <bauzas> Uggla: yes, there are, see the big fat comment on top of the code, by the link I passed
16:23:25 <bauzas> Uggla: fancy proposing the bump ?
16:23:55 <gibi> feel free to ping me for review
16:24:14 <bauzas> thanks gibi
16:24:16 <Uggla> yep I can provide the patch early next week.
16:24:35 <gibi> Uggla: thanks for taking this
16:24:44 <bauzas> #agreed Uggla will propose the QEMU/libvirt versions bump this cycle so people may review the proposal
16:24:57 <bauzas> moving on
16:25:05 <bauzas> a procedural note,
16:25:17 <bauzas> (bauzas) This is my last PTL term
16:25:18 <Uggla> I will also propose the release for trait if that's ok for you ?
16:25:34 <bauzas> Uggla: which trait ?
16:25:38 <gibi> Uggla: sure go ahead
16:25:51 <sean-k-mooney> bauzas: oh sorry
16:25:59 <sean-k-mooney> i was distracted
16:26:02 <bauzas> oh you meant the os-trait release patch ? sure, but please wait until next week as said before
16:26:07 <gibi> if in the meantime we get the patches for the vTPM traits the we can hold the release a bit but I suggest to just do one more release if needed
16:26:09 <Uggla> bauzas, yes
16:26:26 <bauzas> sean-k-mooney: no worries, we'll get back to you in a sec
16:26:29 <gibi> releases are quick an cheap
16:26:42 <bauzas> so, about the PTL seat, I'll leave it
16:27:00 <bauzas> as a reminder, elections start on Feb 5
16:27:12 <bauzas> voilà, it was mostly a FYI
16:27:36 <gibi> bauzas: thank you for your service
16:27:41 <bauzas> (as you've seen, my upstream involvment on Nova decreased a bit so I need to give me more time to do real work)
16:28:00 <elodilles> indeed, thanks so far bauzas o/
16:28:25 <Uggla> thx bauzas for the PRL service.
16:28:39 <fwiesel> bauzas: Thanks a lot!
16:28:59 <Uggla> I think I will be a candidate for the PTL seat. bauzas almost convinced me. :)
16:29:03 <bauzas> thanks, I appreciated that seat but now the cushion has my bottom nearly printed on it *on it since I seated too long
16:29:28 <bauzas> I don't want to convince anyone, it's an election
16:29:45 <bauzas> but I appreciate people volunteering for that service
16:29:50 <Uggla> Of course.
16:30:02 <bauzas> as a reminder, I won't disappear and I'll of course help the new PTL
16:30:43 <bauzas> whoever is elected
16:31:13 <bauzas> anyway, that reminds me I have to start to draft next PTG agenda
16:31:41 <bauzas> of course, I won't run it but the next person will appreciate to have it ready
16:31:58 <bauzas> anyway, done on that procedural note
16:32:04 <bauzas> moving on
16:32:12 <bauzas> back to sean-k-mooney's point
16:32:23 <bauzas> (sean-k-mooney) disable the heal instance info cache periodic
16:32:29 <bauzas> sean-k-mooney: around now ?
16:32:33 <sean-k-mooney> ya so context
16:33:26 <sean-k-mooney> about 2-3 years ago the neturon folks started seeing higher then expecte background load the neutorn server api in bug reports form upstream/downstream custoemrs
16:34:05 <sean-k-mooney> after some invstatiation thaty raised the topic of our periodic heal action in a neutron nova cross project session and asked is it really needed
16:34:12 <bauzas> indeed
16:34:25 <sean-k-mooney> at the time we determined that it should not be but it kind of fell off our radar
16:34:27 <bauzas> I do also remember some OpenInfra talks about that
16:34:55 <sean-k-mooney> recently this has come up again down stream and i wanted to bring th topic back upstrem
16:35:04 <sean-k-mooney> so there are two patches related to this in flight
16:35:18 <sean-k-mooney> the first just test disabling the perodic in nova next
16:35:32 <sean-k-mooney> i belive tha that has already merged
16:35:40 <sean-k-mooney> the second which is what i wanted to dicuss
16:35:53 <sean-k-mooney> is how do we feel about finally disbaling the perodic by default
16:36:19 <bauzas> given the operator feedback I heard, I'm pro-this
16:36:34 <sean-k-mooney> i would like to propose doign it this cycle but if we want to leave it back in the nova-next job to get more data that also a path forward
16:36:43 <bauzas> sean-k-mooney: here's my proposal,
16:37:07 <bauzas> send a thread to openstack-discuss by notifying the ops that we plan to do it this cycle
16:37:13 <bauzas> link to the proposed patch
16:37:29 <bauzas> and if nobody argues by the next weeks, then we can merge it
16:37:47 <bauzas> my bet is that operators will appreciate the default disabling
16:37:59 <sean-k-mooney> ok i can do that
16:38:15 <sean-k-mooney> shal we set a date to check back. say 2 weeks?
16:38:27 <sean-k-mooney> i would prefer not to wiat rith to FF to change the default
16:38:49 <sean-k-mooney> in case we decied we need to revert it
16:38:53 <bauzas> good point
16:39:07 <bauzas> yeah, 2 weeks seems a reasonable trade-off
16:39:07 <masahito> I agree the default change as a large scale OpenStack operator. it's nice update.
16:39:14 <bauzas> we have 5 weeks to FF
16:39:25 <bauzas> that would leave 3 weeks with the change running in CI
16:40:05 <sean-k-mooney> ack ill send a mail to the list later today
16:40:10 <gibi> I'm OK with the 2 weeks notice
16:40:45 <sean-k-mooney> the proceedign patch https://review.opendev.org/c/openstack/nova/+/939453/1
16:40:51 <sean-k-mooney> hasnet actully merge yet
16:41:05 <sean-k-mooney> that is just testing disabling it in nova-next only
16:41:18 <sean-k-mooney> if there is no objection ill recheck that
16:41:36 <sean-k-mooney> and that gives ues 2 addtional weeks fo feedback in the nova-next job while we wait
16:41:52 <bauzas> indeed
16:41:58 <bauzas> sounds a plan
16:42:42 <bauzas> #agreed sean-k-mooney will notify openstack-discuss about disabling by default the instance info cache and give a 2-week notice for disagreements
16:42:53 <bauzas> cool
16:42:56 <bauzas> moving on
16:43:55 <bauzas> (hemanth) Request for review - Compute memory monitor
16:43:59 <bauzas> is hemanth here?
16:44:48 <bauzas> looks not
16:44:51 <sean-k-mooney> so we have said no to extenind that inteface to coolect memory stats in the past
16:45:07 <sean-k-mooney> this would be a spec or specless blueprint too right
16:45:10 <bauzas> and this is a feature request, which would require an approval exception
16:45:27 <bauzas> given we're past the Feature Approval Freeze deadline
16:45:52 <sean-k-mooney> https://docs.openstack.org/nova/latest/contributor/policies.html#metrics-gathering
16:45:56 <gibi> yeah put it on the next PTG agenda
16:46:04 <sean-k-mooney> that speicficly stats that we wont implement new monditors
16:46:04 <bauzas> I'm particularly not against discussing that feature with the owner but not this cycle
16:46:16 <sean-k-mooney> that was added after intel propeosed extending this for numa/memory metrics
16:46:48 <sean-k-mooney> so we can revisit this but it would be a direct revsersal fo that proabition on new monitors
16:47:11 <bauzas> agreed, this is a broad discussion
16:47:54 <bauzas> and I'd want to have it done with a quorum
16:48:20 <bauzas> I agree with gibi, we could add it tothe PTG (provided I create the PTG agenda)
16:48:34 <sean-k-mooney> yep ptg disccsion woudl be good
16:49:17 <gibi> yeah so give the discussion a space and time but set expectation with hemanth that this is not an easy one due to the policy in place
16:49:24 <bauzas> tbc, one of the options being "continue to disregard any other monitors" or even "deprecate the CPU one"
16:50:03 <sean-k-mooney> so the exisitn inteface is currently frozen
16:50:10 <bauzas> gibi: 100% agreed, we would need to understand the usecase and why this is crucial to have Nova supporting such monitors
16:50:14 <sean-k-mooney> and we partly reverted the merged numa code
16:50:26 <sean-k-mooney> because of the perfoamce impact on the rpc bus
16:50:40 <sean-k-mooney> however i do know that peopel use the existing cpu monitor
16:50:49 <sean-k-mooney> namely our internal redhat cloud uses it
16:51:03 <sean-k-mooney> and it massivly helped them with there workload schdduleing
16:51:45 <bauzas> perhaps, but there are limitations that people need to understand
16:51:52 <sean-k-mooney> the specificly use the host cpu load metric via the metrics weigher to avoid hevlilly loaded hosts when placing new instnaces
16:52:13 <bauzas> I know, that's the most common usecase
16:52:54 <bauzas> as I said, there are usecases but also limitations
16:53:18 <bauzas> like, the timewindow is pretty large and if you rely your cloud capacity on such timewindow, you're a fool
16:53:35 <sean-k-mooney> yep we dont need to preempt the ptg topic
16:53:56 <sean-k-mooney> well i disagre with that statement but anyway there are lots of dragons here
16:54:15 <sean-k-mooney> the metrics are sent as aprt fo each schduelr report
16:55:04 <sean-k-mooney> anywya i think we can move on
16:55:46 <bauzas> #agreed as the current design policy explicitely avoiding new monitors, this feature requires a quorum and a long discussion to evaluate a policy revision, hence the Nova community proposing to revisit that topic at the PTG
16:56:00 <bauzas> sean-k-mooney: every 60 secs, right ? :)
16:56:17 <bauzas> (by default of course)
16:56:53 <bauzas> I'm just saying that planning your cloud capacity on a 60-sec time window is nice but not helpful
16:57:09 <bauzas> anyway, we're mostly at time
16:57:19 <bauzas> anything else ?
16:57:23 <gibi> -
16:57:42 <bauzas> thanks all
16:57:46 <bauzas> #endmeeting