Open Stack

On Mon, Feb 23, 2015 at 8:49 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/20/2015 07:16 PM, Joshua Harlow wrote:
> > Sean Dague wrote:
> >> On 02/20/2015 12:26 AM, Adam Gandelman wrote:
> >>> Its more than just the naming.  In the original proposal,
> >>> requirements.txt is the compiled list of all pinned deps
> >>> (direct and transitive), while
> >>> requirements.in<http://requirements.in>  reflects what people
> >>> will actually use.  Whatever is in requirements.txt affects the
> >>> egg's requires.txt. Instead, we can keep requirements.txt
> >>> unchanged and have it still be the canonical list of
> >>> dependencies, while
> >>> reqiurements.out/requirements.gate/requirements.whatever is an
> >>> upstream utility we produce and use to keep things sane on our
> >>> slaves.
> >>>
> >>> Maybe all we need is:
> >>>
> >>> * update the existing post-merge job on the requirements repo
> >>> to produce a requirements.txt (as it does now) as well the
> >>> compiled version.
> >>>
> >>> * modify devstack in some way with a toggle to have it process
> >>> dependencies from the compiled version when necessary
> >>>
> >>> I'm not sure how the second bit jives with the existing
> >>> devstack installation code, specifically with the libraries
> >>> from git-or-master but we can probably add something to warm
> >>> the system with dependencies from the compiled version prior to
> >>> calling pip/setup.py/etc <http://setup.py/etc>
> >>
> >> It sounds like you are suggesting we take the tool we use to
> >> ensure that all of OpenStack is installable together in a unified
> >> way, and change it's installation so that it doesn't do that any
> >> more.
> >>
> >> Which I'm fine with.
> >>
> >> But if we are doing that we should just whole hog give up on the
> >> idea that OpenStack can be run all together in a single
> >> environment, and just double down on the devstack venv work
> >> instead.
> >
> > It'd be interesting to see what a distribution (canonical,
> > redhat...) would think about this movement. I know yahoo! has been
> > looking into it for similar reasons (but we are more flexibly then
> > I think a packager such as canonical/redhat/debian/... would/culd
> > be). With a move to venv's that seems like it would just offload
> > the work to find the set of dependencies that work together (in a
> > single-install) to packagers instead.
> >
> > Is that ok/desired at this point?
> >
>
> Honestly, I failed to track all the different proposals. Just saying
> from packager perspective: we absolutely rely on requirements.txt not
> being a list of hardcoded values from pip freeze, but present us a
> reasonable freedom in choosing versions we want to run in packaged
> products.
>
>
in short the current proposal for stable branches is:

keep requirements.txt as is, except maybe put some upper bounds on the
requirements.

Add requirements.gate to specify the *exact* versions we are gating against
(this would be a full list including all transitive dependencies).


> That's why I asked before we should have caps and not pins.
>
> /Ihar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU61oJAAoJEC5aWaUY1u57T7cIALySnlpLV0tjrsTH2gZxskH+
> zY+L6E/DukFNZsWxB2XSaOuVdVaP3Oj4eYCZ2iL8OoxLrBotiOYyRFH29f9vjNSX
> h++dErBr0SwIeUtcnEjbk9re6fNP6y5Hqhk1Ac+NSxwL75KlS3bgKnJAhLA08MVB
> 5xkGRR7xl2cuYf9eylPlQaAy9rXPCyyRdxZs6mNjZ2vlY6hZx/w/Y7V28R/V4gO4
> qsvMg6Kv+3urDTRuJdEsV6HbN/cXr2+o543Unzq7gcPpDYXRFTLkpCRV2k8mnmA1
> pO9W10F1FCQZiBnLk0c6OypFz9rQmKxpwlNUN5MTMF15Et6DOxGBxMcfr7TpRaQ=
> =WHOH
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> 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/20150223/cb16f684/attachment.html>