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 <[email protected]> wrote: > >> On Tue, Jan 7, 2014 at 3:22 PM, Fox, Kevin M <[email protected]> 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 [[email protected]] >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > -- James Slagle > -- > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
