Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-30
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 zigo bauzas: Are you sure we wont break Folsom ? :P
16:17:04 bauzas it's more a distro thing
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 gibi I have no objection to bump to the next
16:19:16 sean-k-mooney as long as we dont just require latest
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 zigo (which only very rarely happen)
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: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 elodilles #info open stable/zed patches were abandoned, cherry pick them to unmaintained/zed if needed
16:25:56 bauzas cool
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:07 bauzas ++
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 zigo zed is what's in bookworm ... :/
16:26:57 sean-k-mooney are we expecting the default brances for grenade to be updated on stable/antelope centrally
16:27:03 elodilles bauzas: yepp
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 sean-k-mooney i have not had time to re review but ill try and get to it today
16:30:38 bauzas but dan and sean already did their work
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.

Earlier   Later