<div dir="ltr">Hi,<div>I just would like to put my 2 cents on the general idea of having something like we had lower-constraints testing (on master in networking we still have l-c job, but not on stable branches).</div><div>I think generally everybody agrees that such testing can be really helpful for distro builders for example.</div><div>The issue is that there is nobody to keep these requirement lists continuously under control.</div><div><br></div><div>Cheers,</div><div>Lajos Katona (lajoskatona)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> ezt írta (időpont: 2022. febr. 21., H, 14:17):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/18/22 18:33, Brian Rosmaita wrote:<br>
> On 2/18/22 11:42 AM, Thomas Goirand wrote:<br>
>> Hi,<br>
>><br>
>> I've been quite surprised to see $topic. Most requirements for <br>
>> os-brick are now to be found in Yoga only. I've asked why, and I've <br>
>> been told that the reason is because "we've been testing with the new <br>
>> versions only for the number of months".<br>
>><br>
>> Well, the reason why someone would increase a minimum requirement <br>
>> *must* be only because of the need of a new feature, and should be <br>
>> treated with care. Otherwise, this makes upgrading very dangerous and <br>
>> annoying to do. As much as possible, I would strongly recommend that <br>
>> any dependency in Stable can be found in Stable-1 (only when a new <br>
>> feature is mandatory, then it's ok-ish to require that new version, <br>
>> though I would advocate for a possible fallback if that's not too <br>
>> complex to write).<br>
>><br>
>> Now, if that's the path we're taking, all is going backward 5 years <br>
>> ago, and then my thinking is: we must reintroduce lower-constraints <br>
>> testing ASAP.<br>
>><br>
>> Your thoughts everyone?<br>
> <br>
> It would be nice to have clear guidance on this.  I tried to get <br>
> pre-release comments about what I planned to do with os-brick, but maybe <br>
> I didn't allow enough time or had an unclear subject line:<br>
> <br>
> <a href="http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027192.html</a><br>
<br>
I saw the message, but reading it, it wasn't clear enough what the <br>
intention was, and TBH, I probably read the patch too quickly.<br>
<br>
> My concern about keeping the minima low is that what we're actually <br>
> testing with in the gate is pretty much whatever's in upper constraints. <br>
> The previous lower-constraint job basically just checked to see if you <br>
> could co-install the minimum versions of dependencies and run pass unit <br>
> tests within a single project, which doesn't seem very realistic.<br>
<br>
It was catching API / ABI breakage, which was the intention.<br>
<br>
> In any case, it would be better to have an openstack-wide policy so we <br>
> can raise minima in a coordinated way, rather than me forcing everyone <br>
> who uses os-brick to do whatever I do.<br>
<br>
That's what the global-requirements were supposed to be about, however, <br>
as far as the CI is concerned, now only the upper-constraints.txt are in <br>
use, resulting in now useless requirements.txt.<br>
<br>
I very much see a huge regression here, compared to what we had maybe 2 <br>
years ago.<br>
<br>
Indeed, we need to have a (more) global thinking OpenStack wide about <br>
what we should do. I still believe that all project should be able as <br>
much as possible to run with all the requirements from stable -1, to <br>
ease upgrading. This way, it's possible to:<br>
1/ upgrade all services without updating the libs<br>
2/ then upgrade the libs<br>
3/ and finally restart all services.<br>
<br>
without troubles with co-existing services. Requiring a lib from the <br>
current release means that potentially, during the upgrade, an older <br>
service may run with a library from oldstable+1, which that service <br>
doesn't know about (yet). If that's not always possible, it's of course <br>
IMO ok to allow exceptions, if they are under control, and if we make <br>
sure there's no backward breakage (which can only be checked manually).<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div>