Open Stack

Excerpts from Dan Prince's message of 2014-01-09 11:56:16 -0700:
> 
> ----- Original Message -----
> > From: "Derek Higgins" <derekh at redhat.com>
> > To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> > Sent: Thursday, January 9, 2014 8:13:53 AM
> > Subject: [openstack-dev] os-*-config in tripleo repositories
> > 
> > It looks like we have some duplication and inconsistencies on the 3
> > os-*-config elements in the tripleo repositories
> > 
> > os-apply-config (duplication) :
> >    We have two elements that install this
> >      diskimage-builder/elements/config-applier/
> >      tripleo-image-elements/elements/os-apply-config/
> > 
> >    As far as I can tell the version in diskimage-builder isn't used by
> > tripleo and the upstart file is broke
> > ./dmesg:[   13.336184] init: Failed to spawn config-applier main
> > process: unable to execute: No such file or directory
> > 
> >    To avoid confusion I propose we remove
> > diskimage-builder/elements/config-applier/ (or deprecated if we have a
> > suitable process) but would like to call it out here first to see if
> > anybody is using it or thinks its a bad idea?
> > 
> > inconsistencies
> >   os-collect-config, os-refresh-config : these are both installed from
> > git into the global site-packages
> >   os-apply-config : installed from a released tarball into its own venv
> > 
> >   To be consistent with the other elements all 3 I think should be
> > installed from git into its own venv, thoughts?
> 
> These all sound good to me and I've got no issues with cleaning these up.
> 
> I'm not the biggest fan of having multiple venv's for each component though. Especially now that we have a global requirements.txt file where we can target a common baseline. Multiple venvs causes lots of duplicated libraries and increased image build time. Is anyone planning on making consolidated venv's an option? Or perhaps even just using a consolidated venv as the default where possible.
> 

It should probably be an option, as it is helpful to keep things isolated
in CD where requirements do not stabilize all together, but for stable
releases it would make a lot of sense.