[openstack-dev] os-*-config in tripleo repositories
clint at fewbar.com
Thu Jan 9 23:45:09 UTC 2014
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.
More information about the OpenStack-dev