Open Stack

On 27 August 2015 at 02:15, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

>> I really wish that nothing of this kind was even possible. Adding
>> such an upper cap is like hiding the dust under the carpet: it
>> doesn't remove the issue, it just hides it. We really have too much
>> of these in OpenStack. Fixing broken tests was the correct thing to
>> do, IMO.
>>
>
> I think whoever is interested in raising a cap is free to send patches
> and get it up. I don't think those patches would be blocked.

So this is the situation.

In Kilo we have only one mechanism to defend against new releases that
are incompatible: version caps in project trees. Its possible but ugly
and prone to confusing errors, to express 'only use versions up to Y
to test this'. vs 'only use versions up to Y for this'[*]

In Liberty we have constraints, which apply globally across all
projects and give us a safety net, this will be available on
stable/liberty once its created.

So lifting the caps on kilo - won't work, please don't waste your own
or others time trying.
Lifing the caps on liberty - won't be needed, we're not putting them
in in the first place. Folk like packagers that need to know the
'tested compatible versions of dependencies' will be advised to look
in upper-constraints.txt.

At the M summit I intend to drive discussion about getting the
libraries back to a rolling release model, now that we're
de-aggregating 'The Release' we're culturally aligning with these tree
boundaries being contract boundaries, and working with any older
supported release across those boundaries. If we can do that then one
of the major drivers around caps will cease to be relevant (which was
making sure that stable/server-X works with stable/library-Y even
though there are newer releases of library-X up on PyPI. This stops
being important if the statement we make isn't 'here is a release as a
bundle' but is instead 'server-X uses library-Y and needed version
a.b.c at release time'. There are obviously CI and API evolution
factors at play: its not a simple or trivial discussion, but it is one
strongly implied by non-lockstep releases of the servers. (IMO at
least :)).

*: The pitfalls are as follows:
 - projects can't express different rules in install_requires vs
test-requirements.txt because of the requirements syncing checks
 - so the requirements have to be expressed in a non-synced file
 - even then, they can't be presented to pip twice or it will error,
so you have to ensure that none of the testing does 'pip install -r
requirements.txt -r test-requirements.txt -r thisnewfile ...' or it
will bail, which means 'pip install -r test-requirements.txt -r
thisnewfile' and let requirements.txt come in via the egg info
reflection in pbr; which means url deps (deprecated anyway) won't
work.
 - but devs can still be confused
 - and ordering issues can make surprising choices about dep versions
done this way due to pips resolver limitations

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