Open Stack

-----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.

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-----