Open Stack

On Thu, Dec 8, 2016 at 4:27 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> 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:opens
>> tack/glance+branch:stable/liberty+topic:liberty-constraints
>>     <https://review.openstack.org/#/q/status:merged+project:open
>> stack/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).
>
>
Thank you for the link and explanation. I had no idea these constraints
files existed. I will incorporate them into my playbooks and see if that
smooths out my experience deploying from source.

The constraints file, for those following along:
https://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka

Used like this:
pip install -r requirements.txt -c upper-constraints.txt

Further reading:
https://pip.pypa.io/en/stable/user_guide/#constraints-files

Thanks again.



>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161208/81542aa1/attachment.html>