[openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Chris Jones cmsj at tenshu.net
Tue Jan 7 20:51:15 UTC 2014


Hi

(FWIW I suggested using the element arguments like "nova/package" to avoid a huge and crazy environment  by using DIB_REPO foo for every element)

Cheers,
--
Chris Jones

> On 7 Jan 2014, at 20:32, James Slagle <james.slagle at gmail.com> wrote:
> 
>> 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
> --
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list