[all][tc] Dropping lower-constraints testing from all projects
rosmaita.fossdev at gmail.com
Fri Jan 8 15:21:51 UTC 2021
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.
> 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.
More information about the openstack-discuss