<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 12:10 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Feb 20, 2015, at 02:07 PM, Joe Gordon wrote:<br>
> On Fri, Feb 20, 2015 at 7:27 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
> wrote:<br>
><br>
> ><br>
> ><br>
> > On Fri, Feb 20, 2015, at 06:06 AM, Sean Dague wrote:<br>
> > > On 02/20/2015 12:26 AM, Adam Gandelman wrote:<br>
> > > > Its more than just the naming.  In the original proposal,<br>
> > > > requirements.txt is the compiled list of all pinned deps (direct and<br>
> > > > transitive), while <a href="http://requirements.in" target="_blank">requirements.in</a> <<a href="http://requirements.in" target="_blank">http://requirements.in</a>> reflects<br>
> > > > what people will actually use.  Whatever is in requirements.txt affects<br>
> > > > the egg's requires.txt. Instead, we can keep requirements.txt unchanged<br>
> > > > and have it still be the canonical list of dependencies, while<br>
> > > > reqiurements.out/requirements.gate/requirements.whatever is an upstream<br>
> > > > utility we produce and use to keep things sane on our slaves.<br>
> > > ><br>
> > > > Maybe all we need is:<br>
> > > ><br>
> > > > * update the existing post-merge job on the requirements repo to<br>
> > produce<br>
> > > > a requirements.txt (as it does now) as well the compiled version.<br>
> > > ><br>
> > > > * modify devstack in some way with a toggle to have it process<br>
> > > > dependencies from the compiled version when necessary<br>
> > > ><br>
> > > > I'm not sure how the second bit jives with the existing devstack<br>
> > > > installation code, specifically with the libraries from git-or-master<br>
> > > > but we can probably add something to warm the system with dependencies<br>
> > > > from the compiled version prior to calling pip/<a href="http://setup.py/etc" target="_blank">setup.py/etc</a><br>
> > > > <<a href="http://setup.py/etc" target="_blank">http://setup.py/etc</a>><br>
> > ><br>
> > > It sounds like you are suggesting we take the tool we use to ensure that<br>
> > > all of OpenStack is installable together in a unified way, and change<br>
> > > it's installation so that it doesn't do that any more.<br>
> > ><br>
> > > Which I'm fine with.<br>
> > ><br>
> > > But if we are doing that we should just whole hog give up on the idea<br>
> > > that OpenStack can be run all together in a single environment, and just<br>
> > > double down on the devstack venv work instead.<br>
> ><br>
> > I don't disagree with your conclusion, but that's not how I read what he<br>
> > proposed. :-)<br>
> ><br>
> ><br>
> Sean was reading between the lines here. We are doing all this extra work<br>
> to make sure OpenStack can be run together in a single environment, but<br>
> it<br>
> seems like more and more people are moving away from deploying with that<br>
> model anyway. Moving to this model would require a little more then just<br>
> installing everything in separate venvs.  We would need to make sure we<br>
> don't cap oslo libraries etc. in order to prevent conflicts inside a<br>
> single<br>
<br>
</div></div>Something I've noticed in this discussion: We should start talking about<br>
"our" libraries, not just "Oslo" libraries. Oslo isn't the only project<br>
managing libraries used by more than one other team any more. It never<br>
really was, if you consider the clients, but we have PyCADF and various<br>
middleware and other things now, too. We can base our policies on what<br>
we've learned from Oslo, but we need to apply them to *all* libraries,<br>
no matter which team manages them.<br>
<span class=""><br></span></blockquote><div><br></div><div>My mistake, you are correct. I was incorrectly using oslo as a shorthand for all openstack libraries. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> service. And we would still need a story around what to do with stable<br>
> branches, how do we make sure new libraries don't break stable branches<br>
> --<br>
> which in turn can break master via grenade and other jobs.<br>
<br>
</span>I'm comfortable using simple caps based on minor number increments for<br>
stable branches. New libraries won't end up in the stable branches<br>
unless they are a patch release. We can set up test jobs for stable<br>
branches of libraries to run tempest just like we do against master, but<br>
using all stable branch versions of the source files (AFAIK, we don't<br>
have a job like that now, but I could be wrong).<br></blockquote><div><br></div><div>In general I agree, this is the right way forward for openstack libraries. But as made clear this week, we will have to be a little more careful about what is a valid patch release.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm less confident that we have identified all of the issues with more<br>
limited pins, so I'm reluctant to back that approach for now. That may<br>
be an excess of caution on my part, though.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> > Joe wanted requirements.txt to be the pinned requirements computed from<br>
> > the list of all global requirements that work together. Pinning to a<br>
> > single version works in our gate, but makes installing everything else<br>
> > together *outside* of the gate harder because if the projects don't all<br>
> > sync all requirements changes pretty much at the same time they won't be<br>
> > compatible.<br>
> ><br>
> > Adam suggested leaving requirements.txt alone and creating a different<br>
> > list of pinned requirements that is *only* used in our gate. That way we<br>
> > still get the pinning for our gate, and the values are computed from the<br>
> > requirements used in the projects but they aren't propagated back out to<br>
> > the projects in a way that breaks their PyPI or distro packages.<br>
> ><br>
> > Another benefit of Adam's proposal is that we would only need to keep<br>
> > the list of pins in the global requirements repository, so we would have<br>
> > fewer tooling changes to make.<br>
> ><br>
> > Doug<br>
> ><br>
> > ><br>
> > >       -Sean<br>
> > ><br>
> > > --<br>
> > > Sean Dague<br>
> > > <a href="http://dague.net" target="_blank">http://dague.net</a><br>
> > ><br>
> > ><br>
> > __________________________________________________________________________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe:<br>
> > > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>