[all] [requirements] Analysing inflation of requirements in os-brick (was: Artificially inflated requirements in os-brick)

Thomas Goirand zigo at debian.org
Tue Feb 22 16:56:15 UTC 2022

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 
> 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:

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?


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list