Open Stack

On Tue, Jan 7, 2014 at 3:22 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> Sounds very useful. Would there be a diskimage-builder flag then to say you prefer packages over source? Would it fall back to source if you specified packages and there were only source-install.d for a given element?

Yes, you could pick which you wanted via environment variables.
Similar to the way you can pick if you want git head, a specific
gerrit review, or a released tarball today via $DIB_REPOTYPE_<name>,
etc.  See: https://github.com/openstack/diskimage-builder/blob/master/elements/source-repositories/README.md
for more info about that.

If you specified something that didn't exist, it should probably fail
with an error.  The default behavior would still be installing from
git master source if you specified nothing though.


>
> Thanks,
> Kevin
> ________________________________________
> From: James Slagle [james.slagle at gmail.com]
> Sent: Tuesday, January 07, 2014 12:01 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [TripleO] Installing from packages in  tripleo-image-elements
>
> Hi,
>
> I'd like to discuss some possible ways we could install the OpenStack
> components from packages in tripleo-image-elements.  As most folks are
> probably aware, there is a "fork" of tripleo-image-elements called
> tripleo-puppet-elements which does install using packages, but it does
> so using Puppet to do the installation and for managing the
> configuration of the installed components.  I'd like to kind of set
> that aside for a moment and just discuss how we might support
> installing from packages using tripleo-image-elements directly and not
> using Puppet.
>
> One idea would be to add support for a new type (or likely 2 new
> types: rpm and dpkg) to the source-repositories element.
> source-repositories already knows about the git, tar, and file types,
> so it seems somewhat natural to have additional types for rpm and
> dpkg.
>
> A complication with that approach is that the existing elements assume
> they're setting up everything from source.  So, if we take a look at
> the nova element, and specifically install.d/74-nova, that script does
> stuff like install a nova service, adds a nova user, creates needed
> directories, etc.  All of that wouldn't need to be done if we were
> installing from rpm or dpkg, b/c presumably the package would take
> care of all that.
>
> We could fix that by making the install.d scripts only run if you're
> installing a component from source.  In that sense, it might make
> sense to add a new hook, source-install.d and only run those scripts
> if the type is a source type in the source-repositories configuration.
>  We could then have a package-install.d to handle the installation
> from the packages type.   The install.d hook could still exist to do
> things that might be common to the 2 methods.
>
> Thoughts on that approach or other ideas?
>
> I'm currently working on a patchset I can submit to help prove it out.
>  But, I'd like to start discussion on the approach now to see if there
> are other ideas or major opposition to that approach.
>
> --
> -- James Slagle
> --
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
-- James Slagle
--