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