[all][tc] Dropping lower-constraints testing from all projects
gmann at ghanshyammann.com
Mon Jan 11 22:00:54 UTC 2021
---- On Fri, 08 Jan 2021 09:21:51 -0600 Brian Rosmaita <rosmaita.fossdev at gmail.com> wrote ----
> 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?)
Yes, that is the plan. This ML thread is to get initial feedback and then discuss
I have added this to the next TC meeting on the 14th Jan agenda.
> 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.
> > -gmann
More information about the openstack-discuss