On Thu, Dec 8, 2016 at 4:27 PM, Matt Riedemann <[email protected]> wrote:
> On 12/8/2016 4:18 PM, Jason Johnson wrote: > >> >> On Thu, Dec 8, 2016 at 3:48 PM, Matt Riedemann >> <[email protected] <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
