On 2/18/22 17:42, Thomas Goirand wrote:
Hi,
I've been quite surprised to see $topic. Most requirements for os-brick are now to be found in Yoga only. I've asked why, and I've been told that the reason is because "we've been testing with the new versions only for the number of months".
Well, the reason why someone would increase a minimum requirement *must* be only because of the need of a new feature, and should be treated with care. Otherwise, this makes upgrading very dangerous and annoying to do. As much as possible, I would strongly recommend that any dependency in Stable can be found in Stable-1 (only when a new feature is mandatory, then it's ok-ish to require that new version, though I would advocate for a possible fallback if that's not too complex to write).
Now, if that's the path we're taking, all is going backward 5 years ago, and then my thinking is: we must reintroduce lower-constraints testing ASAP.
Your thoughts everyone?
To demonstrate what I'm saying (that we got inflated versions for no reasons), I've analysed some of the version bumps by quickly reviewing the matching git commits.
-oslo.concurrency>=4.4.0 # Apache-2.0 +oslo.concurrency>=4.5.0 # Apache-2.0
A single commit: "Add support for non-blocking locks" The lock() function of lockutils gained a blocking=True default param, that one has to set to False to use the new feature. A quick grep in the os-brick code shows only os_brick/initiator/utils.py uses that function, and doesn't have the "False" blocking param.
-oslo.context>=3.1.1 # Apache-2.0 +oslo.context>=3.4.0 # Apache-2.0
Only this commit is relevant: https://review.opendev.org/c/openstack/oslo.context/+/800852
this is a bug fix, which was backported to all branches since Ussuri.
-oslo.log>=4.4.0 # Apache-2.0 +oslo.log>=4.6.1 # Apache-2.0
- One patch that removes the u in u'' strings... - One config option typo fix. - Some "we run on Python3" commits. - More cosmetic fixes...
-oslo.i18n>=5.0.1 # Apache-2.0 +oslo.i18n>=5.1.0 # Apache-2.0
- A six removal patch. - Some "we use python3" patches. - Some more "we are currently in Xena" patches.
At this point I'm stopping the analysis. It's crystal clear that os-brick requirement version bumps are *NOT* beacause os-brick needs any new feature in these libs, and that it's really artificially inflated just because of the thinking that the gate isn't using older versions ... so we don't easlily know about any possible breakage.
Reality checked: I don't see why it would break. However, it'd be nice to have some more automated ways to do such checks.
These were easily analysed, but it would be harder for eg Eventlet to know if os-brick really needs version 0.30.1. However, it should be a way more easy for a developer of os-brick to know if his change is affecting the minimum requirements. IMO it's at this moment that the bump should happen.
I do understand the "we only tests with the higher bounds", however, again, this may affect upgrades, and it's not reflecting any reality.
Once more: this is not against os-brick, but a higher level thinking. Anyone (even someone not contributing in os-brick) is welcome in this discussion, as I'm trying to discuss here what the OpenStack *policy* should be.
I'm now thinking: we should re-do lower constraints checks!!!
Your thoughts anyone?
Cheers,
Thomas Goirand (zigo)