| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-30 | |||
| 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 | |
| 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. | |