Open Stack

On 12/8/2016 4:18 PM, Jason Johnson wrote:
>
> On Thu, Dec 8, 2016 at 3:48 PM, Matt Riedemann
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>
>     On 12/8/2016 1:03 PM, Ian Cordasco wrote:
>
>
>
>         If your project were using constraints, you would not run into this
>         problem.
>
>
>     I'd like to stress this point. This was the solution for getting
>     glance patches to land in stable/liberty today:
>
>     https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:stable/liberty+topic:liberty-constraints
>     <https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:stable/liberty+topic:liberty-constraints>
>
>     So that we can end of life the stable/liberty branch for Glance.
>
>     Dealing with blacklisting patches is a whack-a-mole approach to deal
>     with the lack of upper-constraints usage in a repo, so the first
>     solution should be to get upper-constraints used in the stable
>     branches on projects (or master for that matter).
>
>
> Exactly. Deploying from a source stable branch should be viable - as it
> stands, it is not. One of the tenets of a stable branch must be
> repeatable from-source builds.
>
> Right now I have "effective pins" in my mitaka Ansible playbooks for
> kombu and keystonemiddleware. This latest kombu kerfuffle broke
> stable/mitaka glance, neutron and nova for me. Keystone broke a few days
> ago.
>
> Is there an existing effort or blueprint or whatever being worked on for
> pinning (or at a minimum setting upper bounds on) dependencies in stable
> branches? If so, I would like to follow and/or participate.
>

Nova already uses upper-constraints for tox jobs (unit tests) in 
stable/mitaka:

https://github.com/openstack/nova/blob/stable/mitaka/tox.ini#L12

devstack has been using upper-constraints for installing from pypi for a 
few releases now.

So the things that need to be using upper-constraints are deployment 
projects, and packagers for that matter. There have been numerous 
threads in the openstack-dev mailing list over the last year and a half 
about requirements/dependency management, pinning, capping, running in 
containers, running in venvs, etc etc etc. The upper-constraints 
solution is what we're using in the upstream CI right now and it's the 
known good list of packages that a given release is tested against 
upstream (note we don't test against the minimum supported versions 
listed in the global-requirements file which is what goes into the 
project repo's requirements.txt file, so those minimums might not even 
work).

-- 

Thanks,

Matt Riedemann