<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 7:00 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
On Mon, Feb 23, 2015, at 06:31 PM, Joe Gordon wrote:<br>
> On Mon, Feb 23, 2015 at 11:04 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
> wrote:<br>
><br>
> ><br>
> ><br>
> > On Mon, Feb 23, 2015, at 12:26 PM, Joe Gordon wrote:<br>
> > > On Mon, Feb 23, 2015 at 8:49 AM, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > -----BEGIN PGP SIGNED MESSAGE-----<br>
> > > > Hash: SHA1<br>
> > > ><br>
> > > > On 02/20/2015 07:16 PM, Joshua Harlow wrote:<br>
> > > > > 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<br>
> > > > >>> (direct and transitive), while<br>
> > > > >>> <a href="http://requirements.in" target="_blank">requirements.in</a><<a href="http://requirements.in" target="_blank">http://requirements.in</a>> reflects what people<br>
> > > > >>> will actually use. Whatever is in requirements.txt affects the<br>
> > > > >>> egg's requires.txt. Instead, we can keep requirements.txt<br>
> > > > >>> unchanged and have it still be the canonical list of<br>
> > > > >>> dependencies, while<br>
> > > > >>> reqiurements.out/requirements.gate/requirements.whatever is an<br>
> > > > >>> upstream utility we produce and use to keep things sane on our<br>
> > > > >>> slaves.<br>
> > > > >>><br>
> > > > >>> Maybe all we need is:<br>
> > > > >>><br>
> > > > >>> * update the existing post-merge job on the requirements repo<br>
> > > > >>> to produce a requirements.txt (as it does now) as well the<br>
> > > > >>> 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<br>
> > > > >>> devstack installation code, specifically with the libraries<br>
> > > > >>> from git-or-master but we can probably add something to warm<br>
> > > > >>> the system with dependencies from the compiled version prior to<br>
> > > > >>> calling pip/<a href="http://setup.py/etc" target="_blank">setup.py/etc</a> <<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<br>
> > > > >> ensure that all of OpenStack is installable together in a unified<br>
> > > > >> way, and change it's installation so that it doesn't do that any<br>
> > > > >> 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<br>
> > > > >> idea that OpenStack can be run all together in a single<br>
> > > > >> environment, and just double down on the devstack venv work<br>
> > > > >> instead.<br>
> > > > ><br>
> > > > > It'd be interesting to see what a distribution (canonical,<br>
> > > > > redhat...) would think about this movement. I know yahoo! has been<br>
> > > > > looking into it for similar reasons (but we are more flexibly then<br>
> > > > > I think a packager such as canonical/redhat/debian/... would/culd<br>
> > > > > be). With a move to venv's that seems like it would just offload<br>
> > > > > the work to find the set of dependencies that work together (in a<br>
> > > > > single-install) to packagers instead.<br>
> > > > ><br>
> > > > > Is that ok/desired at this point?<br>
> > > > ><br>
> > > ><br>
> > > > Honestly, I failed to track all the different proposals. Just saying<br>
> > > > from packager perspective: we absolutely rely on requirements.txt not<br>
> > > > being a list of hardcoded values from pip freeze, but present us a<br>
> > > > reasonable freedom in choosing versions we want to run in packaged<br>
> > > > products.<br>
> > > ><br>
> > > ><br>
> > > in short the current proposal for stable branches is:<br>
> > ><br>
> > > keep requirements.txt as is, except maybe put some upper bounds on the<br>
> > > requirements.<br>
> > ><br>
> > > Add requirements.gate to specify the *exact* versions we are gating<br>
> > > against<br>
> > > (this would be a full list including all transitive dependencies).<br>
> ><br>
> > The gate syncs requirements into projects before installing them. Would<br>
> > we change the sync script for the gate to work from the<br>
> > requirements.gate file, or keep it pulling from requirements.txt?<br>
> ><br>
><br>
> We would only add requirements.gate for stable branches (because we don't<br>
> want to cap/pin things on master). So I think the answer is sync script<br>
> should work for both. I am not sure on the exact mechanics of how this<br>
> would work. Whoever ends up driving this bit of work (I think Adam G),<br>
> will<br>
> have to sort out the details.<br>
<br>
</div></div>OK. I think it's probably worth a spec, then, so we can think it through<br>
before starting work. Maybe in the cross-project specs repo, to avoid<br>
having to create one just for requirements? Or we could modify the<br>
README or something, but the specs repo seems more visible.<br></blockquote><div><br></div><div>Start of the cross project spec <a href="https://review.openstack.org/159249">https://review.openstack.org/159249</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Doug<br>
</font></span><div class=""><div class="h5"><br>
><br>
><br>
> > Doug<br>
> ><br>
> > ><br>
> > ><br>
> > > > That's why I asked before we should have caps and not pins.<br>
> > > ><br>
> > > > /Ihar<br>
> > > > -----BEGIN PGP SIGNATURE-----<br>
> > > > Version: GnuPG v1<br>
> > > ><br>
> > > > iQEcBAEBAgAGBQJU61oJAAoJEC5aWaUY1u57T7cIALySnlpLV0tjrsTH2gZxskH+<br>
> > > > zY+L6E/DukFNZsWxB2XSaOuVdVaP3Oj4eYCZ2iL8OoxLrBotiOYyRFH29f9vjNSX<br>
> > > > h++dErBr0SwIeUtcnEjbk9re6fNP6y5Hqhk1Ac+NSxwL75KlS3bgKnJAhLA08MVB<br>
> > > > 5xkGRR7xl2cuYf9eylPlQaAy9rXPCyyRdxZs6mNjZ2vlY6hZx/w/Y7V28R/V4gO4<br>
> > > > qsvMg6Kv+3urDTRuJdEsV6HbN/cXr2+o543Unzq7gcPpDYXRFTLkpCRV2k8mnmA1<br>
> > > > pO9W10F1FCQZiBnLk0c6OypFz9rQmKxpwlNUN5MTMF15Et6DOxGBxMcfr7TpRaQ=<br>
> > > > =WHOH<br>
> > > > -----END PGP SIGNATURE-----<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>
> > __________________________________________________________________________<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>