| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-30 | |||
| 16:07:59 | bauzas | we don't have jobs testing our minimums, right? | |
| 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:10 | bauzas | we had that before but we removed it AFAICR | |
| 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 | bauzas | if operators skip this release, they still need to upgrade their requirements in the next slurp | |
| 16:10:30 | tkajinam | yeah | |
| 16:10:57 | sean-k-mooney | right but that needed anyway | |
| 16:10:57 | tkajinam | so... stepping back to help people with following the discussion there are a few options we have | |
| 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 | 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 | |