<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 4:27 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 12/8/2016 4:18 PM, Jason Johnson wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
On Thu, Dec 8, 2016 at 3:48 PM, Matt Riedemann<br></span><span class="gmail-">
<<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a> <mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm<wbr>.com</a>>> wrote:<br>
<br>
    On 12/8/2016 1:03 PM, Ian Cordasco wrote:<br>
<br>
<br>
<br>
        If your project were using constraints, you would not run into this<br>
        problem.<br>
<br>
<br>
    I'd like to stress this point. This was the solution for getting<br>
    glance patches to land in stable/liberty today:<br>
<br>
    <a href="https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:stable/liberty+topic:liberty-constraints" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:merged+project:opens<wbr>tack/glance+branch:stable/<wbr>liberty+topic:liberty-constrai<wbr>nts</a><br>
    <<a href="https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:stable/liberty+topic:liberty-constraints" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/q/status:merged+project:open<wbr>stack/glance+branch:stable/<wbr>liberty+topic:liberty-constrai<wbr>nts</a>><br>
<br>
    So that we can end of life the stable/liberty branch for Glance.<br>
<br>
    Dealing with blacklisting patches is a whack-a-mole approach to deal<br>
    with the lack of upper-constraints usage in a repo, so the first<br>
    solution should be to get upper-constraints used in the stable<br>
    branches on projects (or master for that matter).<br>
<br>
<br>
Exactly. Deploying from a source stable branch should be viable - as it<br>
stands, it is not. One of the tenets of a stable branch must be<br>
repeatable from-source builds.<br>
<br>
Right now I have "effective pins" in my mitaka Ansible playbooks for<br>
kombu and keystonemiddleware. This latest kombu kerfuffle broke<br>
stable/mitaka glance, neutron and nova for me. Keystone broke a few days<br>
ago.<br>
<br>
Is there an existing effort or blueprint or whatever being worked on for<br>
pinning (or at a minimum setting upper bounds on) dependencies in stable<br>
branches? If so, I would like to follow and/or participate.<br>
<br>
</span></blockquote>
<br>
Nova already uses upper-constraints for tox jobs (unit tests) in stable/mitaka:<br>
<br>
<a href="https://github.com/openstack/nova/blob/stable/mitaka/tox.ini#L12" rel="noreferrer" target="_blank">https://github.com/openstack/n<wbr>ova/blob/stable/mitaka/tox.ini<wbr>#L12</a><br>
<br>
devstack has been using upper-constraints for installing from pypi for a few releases now.<br>
<br>
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).<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>The constraints file, for those following along:</div><div><a href="https://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka">https://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka</a><br></div><div><br></div><div>Used like this:</div><div>pip install -r requirements.txt -c upper-constraints.txt</div><div><br></div><div>Further reading:</div><div><a href="https://pip.pypa.io/en/stable/user_guide/#constraints-files">https://pip.pypa.io/en/stable/user_guide/#constraints-files</a><br></div><div><br></div><div>Thanks again.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>