16:00:12 <bauzas> #startmeeting nova
16:00:12 <opendevmeet> Meeting started Tue Apr 30 16:00:12 2024 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <opendevmeet> The meeting name has been set to 'nova'
16:00:27 <bauzas> hey folks
16:00:31 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:34 <Uggla_> o/
16:00:37 <tkajinam> o/
16:00:39 <gibi> o/
16:00:41 <auniyal> o/
16:00:41 <elodilles> o/
16:00:51 <fwiesel> \o
16:00:57 <bauzas> cool, let's start
16:01:06 <bauzas> #topic Bugs (stuck/critical)
16:01:12 <bauzas> #info No Critical bug
16:01:19 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:01:23 <bauzas> any bug to report ?
16:01:51 <bauzas> looks not
16:01:56 <bauzas> moving on?
16:02:19 <bauzas> #topic Gate status
16:02:24 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:02:29 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:02:34 <opendevreview> Merged openstack/nova master: reno: Update master for unmaintained/zed  https://review.opendev.org/c/openstack/nova/+/917741
16:02:34 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:02:37 <opendevreview> Merged openstack/placement master: reno: Update master for unmaintained/zed  https://review.opendev.org/c/openstack/placement/+/917747
16:02:41 <bauzas> all greens
16:02:54 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:03:01 <bauzas> #info Please try to provide meaningful comment when you recheck
16:03:15 <bauzas> anything about some gate failure you just found ?
16:03:40 <tkajinam> I noticed that requirements-check job is broken now but I'll talk about that later when we talk about review priorities
16:03:48 <bauzas> ack
16:04:07 <bauzas> #topic Release Planning
16:04:13 <bauzas> #link https://releases.openstack.org/dalmatian/schedule.html
16:04:16 <bauzas> #info Dalmatian-1 in 2 weeks
16:04:22 <bauzas> #action bauzas to add the nova deadlines in the Dalmatian schedule page
16:04:36 <bauzas> I'll do this tomorrow (as I'm done with my devstack problems :) )
16:04:50 <bauzas> #topic Review priorities
16:04:55 <bauzas> #link https://etherpad.opendev.org/p/nova-dalmatian-status
16:05:04 <bauzas> tkajinam: shoot
16:05:19 <opendevreview> Rajesh Tailor proposed openstack/nova master: Fix KeyError on assisted snapshot call  https://review.opendev.org/c/openstack/nova/+/900783
16:05:33 <tkajinam> I've added summary to L52
16:05:38 <bauzas> I see you added it indeed
16:05:56 <tkajinam> requirements-check job is currently broken because old excludes were cleaned up in global requirements file
16:06:36 <tkajinam> because these excludes are no longer maintained in the global requirements repo, I think it makes sense to remove these from individual repo
16:06:38 <sean-k-mooney> yep it sound like we are missing somethign on the requirement repo to have caught that breakage
16:06:53 <bauzas> correct
16:07:03 <bauzas> and I'm afraid to bump our minimums just because of that
16:07:39 <sean-k-mooney> so i think its a bug if we do nto bump
16:07:59 <bauzas> we don't have jobs testing our minimums, right?
16:08:10 <bauzas> we had that before but we removed it AFAICR
16:08:10 <sean-k-mooney> im not really happy about removing know broken verison and not bumping to a version above them as our minium
16:08:20 <sean-k-mooney> correct
16:08:24 <sean-k-mooney> we dont test our miniums
16:08:39 <sean-k-mooney> so i would like to rasied them above any version that was listed as know to have issues
16:08:44 <bauzas> so there is no clear guarantee about the minimums
16:08:46 <sean-k-mooney> we will still use latest in the jobs
16:09:03 <bauzas> the problem is simple : we are on a non-SLURP release
16:09:05 <sean-k-mooney> correct they may be older then we actully require
16:09:20 <sean-k-mooney> why would htat matter
16:09:28 <sean-k-mooney> we are allowed to raise minium in non slurps
16:09:49 <bauzas> oh maybe I was wrong
16:10:11 <tkajinam> +1 to sean, otherwise we can't implement anything which rely on new os-traits thing during this cycle
16:10:14 <opendevreview> Merged openstack/osc-placement master: reno: Update master for unmaintained/zed  https://review.opendev.org/c/openstack/osc-placement/+/917745
16:10:26 <sean-k-mooney> or new release of oslo libs ectra
16:10:30 <tkajinam> yeah
16:10:30 <bauzas> if operators skip this release, they still need to upgrade their requirements in the next slurp
16:10:57 <tkajinam> so... stepping back to help people with following the discussion there are a few options we have
16:10:57 <sean-k-mooney> right but that needed anyway
16:11:07 <tkajinam> 1. just remove old excludes
16:11:10 <sean-k-mooney> i.e. what ever release theyre upgrading too then need ot install its deps
16:11:18 <tkajinam> 2. remove old excludes and bump minimum to effectively excludes these bad versions
16:11:42 <tkajinam> 3. ask requirements to revert the change
16:11:53 <tkajinam> 4. loose the validation to ignore mismatch in excludes
16:12:08 <bauzas> looks like we went to a corner now we no longer have min reqs
16:12:11 <sean-k-mooney> i asked tkajinam to do 2
16:12:35 <bauzas> the problem is that we only test on gate our latest releases in pip
16:12:44 <sean-k-mooney> bauzas: we still have min requirement in our repo we just dont test them
16:13:13 <sean-k-mooney> so i think min version testing is out of scope for right now
16:13:25 <gibi> the fact that we are not testing the minimum is true even without the bump, we just don't know that the current minimums are better than the new ones
16:13:27 <sean-k-mooney> and we should folcus on the 4 optiosn tkajinam has presented
16:13:36 <bauzas> that's the point, we have minimums for flexibility to make sure that operators don't need to update every dependency to latest everytime, right?
16:13:51 <sean-k-mooney> kind of
16:13:53 <bauzas> our support envelope is really "latest"
16:14:02 <elodilles> we have this comment in the req.txt: https://opendev.org/openstack/nova/src/branch/master/requirements.txt#L1-L3
16:14:05 <bauzas> which can change during a release cycle
16:14:07 <sean-k-mooney> its mainly to document to packagers what we thing shoudl work
16:14:15 <gibi> are there any major bumps in the list? minor bumps should be compatible
16:14:24 <bauzas> there are
16:14:36 <bauzas> if we go with bumping
16:14:49 <sean-k-mooney> gibi: we were already crossing major bondaries
16:14:52 <bauzas> https://review.opendev.org/c/openstack/nova/+/917594/1/requirements.txt#b54
16:15:01 <tkajinam> yeah there are
16:15:05 <tkajinam> bauzas, yes, but note that the versions removed from excludes are all 2+ years old
16:15:09 <bauzas> we would be changing our cinderclient min to 4.x
16:15:15 <bauzas> sure
16:15:41 <bauzas> but I don't want zigo to kill me at milestone-3 :)
16:15:45 <gibi> so the only thing that I can foresee if we bump our minor from major to major+1 but our latest we test with is major+2
16:15:54 <sean-k-mooney> right we are currently testign with cinder client 9.5.0
16:15:59 <gibi> tell zigo at m-1
16:16:03 <gibi> :)
16:16:08 <sean-k-mooney> so bumping to 4.x is prablly better then saying it actully works with 3.3.0
16:16:14 <sean-k-mooney> it might but we have not tested that in years
16:16:16 <bauzas> he's highlighted now :D
16:16:46 <sean-k-mooney> well for cinder client we test major +6 now
16:16:49 <zigo> Even buster has 1:4.0.1-2 ... :P
16:16:50 <bauzas> honestly, I don't know how much of that matters
16:17:04 <bauzas> it's more a distro thing
16:17:04 <zigo> bauzas: Are you sure we wont break Folsom ? :P
16:17:38 * zigo reads the backlog, what are we talking about exactly ? requirements ?
16:17:41 <bauzas> zigo: now you're here (glad you continue to listen to us :) ), are you okay with nova bumping their minimums straighly ?
16:17:49 <sean-k-mooney> does anyone object ot bumping to the first release after the last knnow bad relsese ?
16:18:12 <bauzas> after all that discussion, I have to admit I have no objection now
16:18:39 <gibi> based on the current discussion we are affraid to bump the mins, but we are also not doing anything to be less affraid. In the other hand project arond us are moving forward. Either we need to be less affraid or start doing things that makes us less affraid
16:18:54 <bauzas> distro owners seem to be smart folks who actually don't really use our requirements for shipping their own packages
16:19:10 <sean-k-mooney> i personally am not that concerned with bumping the mins on master
16:19:16 <sean-k-mooney> as long as we dont just require latest
16:19:16 <gibi> I have no objection to bump to the next
16:19:18 <zigo> bauzas: I don't mind, and I don't really care the SLURP thingy, because it's 1/ not alligned with Debian in terms of dates 2/ still a 1 year thingy instead of 2.
16:19:24 <sean-k-mooney> we obviously cant do that on stable
16:19:25 <tkajinam> If I hear no immediate objections here then I'll update all patches based on that strategy
16:19:32 <bauzas> and given our minimums are quite (very) old, I think I'm OK with bumpinig
16:19:40 <tkajinam> if you find any concern with specific bumps then we can discuss that in detail
16:19:49 <zigo> Once we switch to a 1 year release and SLURP, effectively supporting debian stable -> stable +1 upgrades, then I'll start to care.
16:19:50 <sean-k-mooney> +2
16:19:55 <bauzas> tkajinam: you know what ? do it, and we'll see if people yell
16:20:12 <tkajinam> most of my patches are based on option 1 (without bump) so have to be updated for option 2.
16:20:34 <tkajinam> bauzas, yup :-)  that's why I created these changes, actually
16:21:05 <zigo> Mostly in distros: we don't need to care about excludes, we just need to *not* package them. :P
16:21:17 <bauzas> #agreed it seems our requirement minimums are actually very old so we all accept to raise the versions of the packages that were having excluded versions to the N+1 release
16:21:17 <zigo> (which only very rarely happen)
16:21:41 <bauzas> zigo: it only happens when the latest version has to be excluded: )
16:21:43 <bauzas> :)
16:21:46 <zigo> Yeah, we're talking about buster to trixie (ie: debian 9 to 13) here ... :P
16:21:52 <fwiesel> Stupid question: are there really people out there that mix and match releases of individual packages in the same python environment? Is that even allowed?
16:22:03 <bauzas> when we talk of 5-yo excluded versions, I think nobody cares
16:22:15 <zigo> fwiesel: It depends what service, for some it's possible.
16:22:26 <bauzas> that's why we have global requirements
16:22:43 <zigo> fwiesel: For example, if you're doing multi-region with a single keystone, it's important that older Keystone is supported by newer rest-of-openstack.
16:22:59 <zigo> Keystone is probably a special case...
16:23:03 <fwiesel> Sure, but that is kind of guaranteed by the microversions.
16:23:14 <tkajinam> I'll update these patches so it'd be nice these can be review with priority. as I said requirements-check job is broken and we need these to merge any changes which update reqs now
16:23:26 <fwiesel> At least we upgrade keystone and other services independently. and use the uppser-constraints of the respective releases of the service.
16:23:28 <bauzas> bumping our minimums puts some stress to some other projects that may also need to upgrade their own minimums, but here we're talking of very old versions
16:23:43 <bauzas> tkajinam: noted, I'll pay my duty
16:23:46 <tkajinam> I've also left the other bug there and that's also nice-to-have thing to unblock our testing glance run by httpd+mod_wsgi in puppet jobs
16:23:59 <tkajinam> but that's not as much urgent now
16:24:21 <bauzas> I was frankly off upstream those weeks but I'm now back
16:24:35 <bauzas> moving on I guess
16:24:39 <tkajinam> that's all from my side
16:24:42 <tkajinam> yup
16:24:51 <bauzas> tkajinam: thanks for having reported it and worked on it
16:25:02 <bauzas> #topic Stable Branches
16:25:10 <bauzas> elodilles: you're next !
16:25:17 <elodilles> o7
16:25:26 <elodilles> #info no recent merges, but stable/202*.* branches' gates should be OK
16:25:35 <elodilles> #info final release for stable zed is out (26.3.0)
16:25:39 <bauzas> shhhh
16:25:49 <elodilles> #info stable/zed transitioned to Unmaintained
16:25:56 <bauzas> cool
16:25:56 <elodilles> #info open stable/zed patches were abandoned, cherry pick them to unmaintained/zed if needed
16:26:07 <bauzas> ++
16:26:07 <elodilles> note:  as with the previous newly opened unmaintained branches, unmaintained/zed gate might need some fixes before we can merge anything there
16:26:27 <elodilles> last but not least:
16:26:31 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:26:41 <bauzas> which means that now all our supported releases follow the SLURP cadence, huzzah
16:26:52 <opendevreview> Takashi Kajinami proposed openstack/placement master: Remove old excludes  https://review.opendev.org/c/openstack/placement/+/917608
16:26:57 <sean-k-mooney> are we expecting the default brances for grenade to be updated on stable/antelope centrally
16:26:57 <zigo> zed is what's in bookworm ... :/
16:27:03 <elodilles> bauzas: yepp
16:27:06 * zigo goes in the corner and cries ...
16:27:24 * bauzas gives tissues to zigo
16:27:30 <opendevreview> Takashi Kajinami proposed openstack/placement master: Remove old excludes  https://review.opendev.org/c/openstack/placement/+/917608
16:27:49 <bauzas> thanks elodilles
16:27:58 <bauzas> anything else on the stable side ?
16:27:59 <elodilles> sean-k-mooney: we had some patches, but i don't know whether that is among them :X
16:28:14 <elodilles> bauzas: np, nothing else from me
16:28:21 <sean-k-mooney> ack so that will cause grenade to fail then since the base barnch wont exist
16:28:40 <sean-k-mooney> but its also a simple enough change once all the branch movign is done
16:28:57 <elodilles> ++
16:28:59 <bauzas> I think grenade has some homework anytime we delete a branch
16:29:15 <bauzas> but let's move on
16:29:21 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:29:37 <bauzas> fwiesel: wanting to say something ?
16:29:47 <fwiesel> Not really.
16:30:02 <fwiesel> https://review.opendev.org/c/openstack/nova/+/909474 has been reviewed, so that's great. Thanks to everyone.
16:30:11 <fwiesel> Any questions?
16:30:27 <sean-k-mooney> am i saw the chagnes that dan asked for
16:30:29 <bauzas> cool, I'll see if I can look at it
16:30:38 <bauzas> but dan and sean already did their work
16:30:38 <sean-k-mooney> i have not had time to re review but ill try and get to it today
16:30:42 <sean-k-mooney> after the meeting
16:30:45 <fwiesel> Thanks
16:30:47 <bauzas> cool so
16:30:51 <fwiesel> #info Nothing to report.
16:30:54 <bauzas> cool
16:30:56 <bauzas> last topic then
16:30:59 <bauzas> let's be short
16:31:01 <sean-k-mooney> asuming that merges can you add the next one to the list for review
16:31:03 <bauzas> #topic Open discussion
16:31:10 <bauzas> I have one thing to raise
16:31:13 <gibi> I have one too
16:31:22 <fwiesel> sean-k-mooney: Of course, I'll add that one
16:31:31 <bauzas> (bauzas) I won't be able to run the next nova meeting
16:31:52 <opendevreview> Takashi Kajinami proposed openstack/nova master: Remove old excludes  https://review.opendev.org/c/openstack/nova/+/917594
16:32:00 <bauzas> (I'll take a few days off starting Wed, but I'll need to travel on Tues by 5pm my time)
16:32:14 <bauzas> so, who can run the meeting in my absence ?
16:32:19 <dansmith> or just cancel?
16:32:25 <bauzas> if nobody volunteers, I can cancel
16:32:28 <bauzas> yeah that
16:32:44 <gibi> I can run it if needed
16:33:09 <bauzas> thanks gibi
16:33:17 <gibi> no problemo
16:33:18 <bauzas> #action gibi to run next nova meeting
16:33:24 <bauzas> gibi: shoot your own point
16:33:31 <gibi> just a heads up
16:34:15 <gibi> we started a small standup with Uggla_ about his manial series 30 mins twice a week. So far it is Uggla_ and me but eventually  we need a second code for the series
16:34:26 <bauzas> count me on it
16:34:27 <gibi> and such core could benefit joining to these meetings
16:34:49 <gibi> bauzas: thanks, I will make sure you will have the invite
16:34:50 <bauzas> I already reviewed the series so I'd be happy to continue to shepherd it
16:35:10 <bauzas> gibi: cool, timezones will then match hopefully :)
16:35:16 <bauzas> (it was a joke)
16:35:20 <gibi> it will :)
16:35:28 <gibi> that is all
16:35:31 <bauzas> cool
16:35:36 <bauzas> and then that's all for me too
16:35:40 <bauzas> thanks all
16:35:42 <opendevreview> Takashi Kajinami proposed openstack/python-novaclient master: Remove old excludes  https://review.opendev.org/c/openstack/python-novaclient/+/917685
16:35:44 <bauzas> was a productive meeting
16:35:48 <bauzas> see you :)
16:35:52 <bauzas> #endmeeting