Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-30
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:10 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: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

Earlier   Later