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