Open Stack

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?

-Josh

>
> 	-Sean
>