Open Stack

On 2/21/22 14:32, Sean Mooney wrote:
> On Mon, 2022-02-21 at 13:27 +0000, Sean Mooney wrote:
>> On Mon, 2022-02-21 at 14:10 +0100, Thomas Goirand wrote:
>>> On 2/18/22 18:33, Brian Rosmaita wrote:
>>>> On 2/18/22 11:42 AM, 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?
>>>>
>>>> It would be nice to have clear guidance on this.  I tried to get
>>>> pre-release comments about what I planned to do with os-brick, but maybe
>>>> I didn't allow enough time or had an unclear subject line:
>>>>
>>>> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html
>>>
>>> I saw the message, but reading it, it wasn't clear enough what the
>>> intention was, and TBH, I probably read the patch too quickly.
>>>
>>>> My concern about keeping the minima low is that what we're actually
>>>> testing with in the gate is pretty much whatever's in upper constraints.
>>>> The previous lower-constraint job basically just checked to see if you
>>>> could co-install the minimum versions of dependencies and run pass unit
>>>> tests within a single project, which doesn't seem very realistic.
>>>
>>> It was catching API / ABI breakage, which was the intention.
>>>
>>>> In any case, it would be better to have an openstack-wide policy so we
>>>> can raise minima in a coordinated way, rather than me forcing everyone
>>>> who uses os-brick to do whatever I do.
>>>
>>> That's what the global-requirements were supposed to be about, however,
>>> as far as the CI is concerned, now only the upper-constraints.txt are in
>>> use, resulting in now useless requirements.txt.
>>>
>>> I very much see a huge regression here, compared to what we had maybe 2
>>> years ago.
>>>
>>> Indeed, we need to have a (more) global thinking OpenStack wide about
>>> what we should do. I still believe that all project should be able as
>>> much as possible to run with all the requirements from stable -1, to
>>> ease upgrading. This way, it's possible to:
>>> 1/ upgrade all services without updating the libs
>>> 2/ then upgrade the libs
>>> 3/ and finally restart all services.
>> much of the feature development actully assume you upgade the libs first
>> then upgrade the service
>> then restart it.
>>
>> doign the libs second make the code in the consuming porject much more difficult to write
>> as we need to have fallbacks but upgrading the libs outside of a breaking major version should
>> not break exisign users.
>>
>> supporting the version of n-1 libs might be worth considering instaed of our older lower constraits aproch
>> but im really not sure we shoudl expect the service in general to be upgraded first. i can kind of see
>> why you woudl like that but that woudl increase the burden on client which i dont think we want to do.
> 
> by the way the reason i prefer the idea of upgrading the lib first is os-vif and all the other lib projects
> already have jobs that install the master verion of the lib with the current release of the projects that use them
> i.e. os-vif is used by nova and neutron so we have a devstack job that ensure we can still work with the current
> master version of nova and neutron. ideally that means we shoudl never break them with a new release.

Oh, this makes me think that what I wrote is not completely accurate. 
While IMO, supporting the stable -1 version of a lib like os-vif and 
os-brick is important, a lib like neutron-lib of course, is bound to a 
specific release of OpenStack and the matching Neutron API. So IMO, the 
reasoning doesn't apply for something like neutron-lib, which contains 
the internal description of the Neutron API. This however, may make 
things difficult to upgrade when having Octavia running on the same 
server as Neutron, but I currently don't see any workaround. Maybe the 
solution is only to make sure that neutron-lib doesn't break the stable 
-1 version of Octavia (for example). So in this case, it's more up to 
neutron-lib to be backward compatible.

Hoping what I wrote makes sense,
Cheers,

Thomas Goirand (zigo)