I was going to stay silent on this one, but since you asked... /me puts his customer hat on
We source OpenStack from RDO for the packages and additional integration testing that comes from the project instead of using OpenStack directly. I was a little turned off from Triple-O when I saw it was source only. The feeling being that it is "too green" for our tastes. Which may be inaccurate. While I might be convinced to use source, its a much harder sell to us currently then using packages. /me takes of his customer hat. Thanks again for all the hard work on Triple-O. Its looking great, and I hope I get the chance to use it soon. Thanks, Kevin ________________________________________ From: Chris Jones [c...@tenshu.net] Sent: Tuesday, January 07, 2014 12:48 PM To: OpenStack Development Mailing List (not for usage questions) Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements Hi Assuming we want to do this, but not necessarily agreeing that we do want to, I would suggest: 1) I think it would be nice if we could avoid separate dpkg/rpm types by having a package type and reusing the package map facility. 2) Clear up the source-repositories inconsistency by making it clear that multiple repositories of the same type do not work in source-repositories-nova (this would be a behaviour change, but would mesh more closely with the docs, and would require refactoring the 4 elements we ship atm with multiple git repos listed) 3) extend arg_to_element to parse element names like "nova/package", "nova/tar", "nova/file" and "nova/source" (defaulting to source), storing the choice for later. 4) When processing the nova element, apply only the appropriate entry in source-repositories-nova 5) Keep install.d as-is and make the scripts be aware of the previously stored choice of element origin in the elements (as they add support for a package origin) 6) Probably rename source-repositories to something more appropriate. As for whether we should do this or not... like Clint I want to say no, but I'm also worried about people forking t-i-e and not pushing their fixes/improvements and new elements back up to us because we're too diverged. If this is a real customer need, I would come down in favour of doing it if the cost of the above implementation (or an alternate one) isn't too high. Cheers, -- Chris Jones > On 7 Jan 2014, at 20:01, James Slagle <james.sla...@gmail.com> wrote: > > 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
