Open Stack

On 1/6/21 12:59 PM, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> You might have seen the discussion around dropping the lower constraints
> testing as it becomes more challenging than the current value of doing it.

I think the TC needs to discuss this explicitly (at a meeting or two, 
not just on the ML) and give the projects some guidance.  I agree that 
there's little point in maintaining the l-c if they're not actually 
useful to anyone in their current state, but if their helpfulness (or 
potential helpfulness) outweighs the maintenance burden, then we should 
keep them.  (How's that for a profound statement?)

Maybe someone can point me to where I can RTFM to get a clearer picture, 
but my admittedly vague idea of what the l-c are for is that it has 
something to do with making packaging easier.  If that's the case, it 
would be good for the TC to reach out to some openstack 
packagers/distributors to find outline how they use l-c (if at all) and 
what changes could be done to make them actually useful, and then we can 
re-assess the maintenance burden.

This whole experience with the new pip resolver has been painful, I 
think, because it hit all projects and all branches at once.  My 
experience, however, is that if I'd been updating the minimum versions 
for all the cinder deliverables in their requirements.txt and l-c.txt 
files every cycle to reflect a pip freeze at Milestone-3 it would have 
been a lot easier.

What do other projects do about this?  In Cinder, we've just been 
updating the requirements on-demand, not proactively, and as a result 
for some dependencies we claimed that foo>=0.9.0 is OK -- but except for 
unit tests in the l-c job, cinder deliverables haven't been using 
anything other than foo>=16.0 since rocky.  So in master, I took 
advantage of having to revise requirements and l-c to make some major 
jumps in minimum versions.  And I'm thinking of doing a pip-freeze 
requirements.txt minimum version update from now on at M-3 each cycle, 
which will force me to make an l-c.txt update too.  (Maybe I was 
supposed to be doing that all along?  Or maybe it's a bad idea?  I could 
use some guidance here.)

It would be good for the l-c to reflect reality, but on the other hand, 
updating the minimum versions in requirements.txt (and hence in l-c) too 
aggressively probably won't help packagers at all.  (Or maybe it will, I 
don't know.)  On the other hand, having the l-c is useful from the 
standpoint of letting you know when your minimum acceptable version in 
requirements.txt will break your unit tests.  But if we're updating the 
minimum versions of dependencies every cycle to known good minimum 
versions, an l-c failure is going to be pretty rare, so maybe it's not 
worth the trouble of maintaining the l-c.txt and CI job.

One other thing: if we do keep l-c, we need to have some guidance about 
what's actually supposed to be in there.  (Or I need to RTFM.)  I've 
noticed that as we've added new dependencies to cinder, we've included 
the dependency in l-c.txt, but not its indirect dependencies.  I guess 
we should have been adding the indirect dependencies all along, too? 
(Spoiler alert: we haven't.)

This email has gotten too long, so I will shut up now.

cheers,
brian

> 
> Few of the ML thread around this discussion:
> 
> - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html
> - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html
> 
> As Oslo and many other project dropping or already dropped it, we should decide it for all
> other projects also otherwise it can be more changing than it is currently.
> 
> We have not defined it in PTI or testing runtime so it is always up to projects if they still
> want to keep it but we should decide a general recommendation here.
> 
> -gmann
>