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.... - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390....
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