Open Stack

On 9 July 2015 at 00:02, Doug Hellmann <doug at doughellmann.com> wrote:
>
> Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200:
> > On 8 July 2015 at 21:01, Thierry Carrez <thierry at openstack.org> wrote:
> > > Robert Collins wrote:
> > >> We've finally gotten all the kinks worked out and now
> > >> upper-constraints proposals should be coming in daily.
> > >>
> > >> *** These are timely and important: without them, no new releases of
> > >> *anything* are consumed. ***
> > >>
> > >> https://review.openstack.org/#/c/199353/ is an example.
> > >>
> > >> They are all in the topic
> > >> https://review.openstack.org/#/q/status:open+topic:openstack/requirements/constraints,n,z
> > >>
> > >> (there is only ever one at a time at the moment, proposed to our
> > >> master requirements repo). After liberty branches there may be
> > >> multiple ones open - one per release of OpenStack that uses
> > >> constraints files.
> > >>
> > >> I'm putting all this into the documentation too, of course.
> > >
> > > I'm wondering if we should not refresh them less often. Some of those
> > > will trigger some discussion before approval
> >
> > ^ if they do, its bogus discussion. We never had discussion previously
> > when new deps flowed into gate jobs willy-nilly - except when it went
> > wrong. The new feature is not a policy knob or control point. Its an
> > automated red-green detector for whether those new dep versions would
> > have broken devstack (and soon unittests too). Debating the right
> > value in upper-constraints.txt is only of relevance to:
> >  - folk working on resolvers in pip
> >  - folk dealing with a bad pin that they need to change - and the
> > input is *not* upper-constraints.txt, its global-requirements.txt as
> > previous.
> >
> > > , and having them constantly
> > > wiped out by new patchsets that add one or two extra bumps is, IMHO,
> > > counter-productive...
> >
> > I'd like to make the job run automatically immediately that we cut a
> > release of anything. And I'd also like to get to the point of
> > confidence in the whole system that we auto-approve them as soon as
> > they go green.
>
> I think that's appropriate for things we're producing. I'm not sure how
> I feel about automatically changing constraints for third-party
> packages. Part of the reason for reviewing those was supposed to be to
> ensure we're not outstripping what the distros are prepared to ship. Do
> we still want to try to keep an eye on that?
<SNIP>

I don't think this change is about adding new requirements, just
better handling of the current version constraints, which has never
been something that has been that tied to distributions, other than
attempting to respect DepFreeze[0].

I'm not sure it can be claimed that those reviewing these changes are
familiar enough with distributions workflow, and those that are close
to distros are probably not as engaged as they could be.

That said, I am not sure it matters for this instance.  Unless I am
mistaken - this is about expanding lower and upper constraints to as
wide range as OpenStack projects can support.. which means that
distributions can continue (as they currently do) to make sure that
their archives fulfil the versions as limited by requirements.txt.
This change actually makes it a better experience for them, as they
have a more deterministic view of what will work.

It doesn't solve the issue of distributions chasing the lowest
version, but I am not sure that is an OpenStack problem to solve.
Regardless of DepFreeze, I'd expect this effort to be growing the
supported external requirements version window rather than causing any
surprises.

[0] https://wiki.openstack.org/wiki/DepFreeze

--
Kind Regards,
Dave Walker