[openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Robert Collins robertc at robertcollins.net
Wed Jul 8 23:17:41 UTC 2015


On 9 July 2015 at 11:02, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200:
>> 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?

That would be a new thing. Until this work was done we reviewed
changes to *untested minimums*. Since all our test infrastructure ran
the latest version it could everywhere, it is very common that our
actual minimum is much lower than our stated minimum. And then we
raise it when someone notices.

I'd like to add in a lower-constraints.txt set of pins and actually
start reporting on whether our lower bounds *work*.

But what we have now is just more visibility and less breakage with in
all other regards the same previous behaviour: running the latest
thing available per global-requirements. If we're going to start
reviewing 'use new thing only if its packaged', I think we're going to
have to ask for many more reviewers - we have nearly 300 packages (274
lines in g-r, 313 in upper-constraints) that change, and making every
release of any of them require actual thought means we'd need much
more review bandwidth.

We could in principle write automation to make our pins honour 'what
is packaged in RHEL+Fedora+Debian+Ubuntu+Suse' - we could have  a
database of the versions present in the distros and translate that to
additional constraints when compiling upper-constraints.txt. So I can
see a way to automate that. If folk are interested in making that
happen, I think that it should proceed as follows:
 - seek consensus that its a needed thing (its not clear that it is to me)
 - draw up a spec (I'll help)
 - implement

Today however, it would be new, and I think we just don't have human
capacity to do it by hand.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list