Open Stack

 ---- 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
in meeting.

I have added this to the next TC meeting on the 14th Jan agenda.

- https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions

-gmann

 > 
 > 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
 > > 
 > 
 > 
 >