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

Reply via email to