Open Stack

On Tue, Jan 7, 2014 at 3:48 PM, Chris Jones <cmsj at tenshu.net> wrote:
> 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.

Indeed, I'd like to see one package type as well. I think we could
start with that route, and only split it out if there was a proven
technical need.

> 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)

Could you expand on this a bit?  I'm not sure what inconsistency
you're referring to.

> 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.

All good ideas.  I like the mechanism to specify the type as well.  I
wonder if we could have a global build option as well that said to use
packages or source, or whatever, for all components that support that
type.  That way you wouldn't have to specify each individually.

> 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.

I feel that not offering a choice will only turn people off from using
t-i-e. Only offering an install from source option is not likely to
cause large groups of people to suddenly decide that only installing
from source is the way to go and then start using t-i-e exclusively.
So, that's why I'd really like to see support for packages in the main
repo itself.

> 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.

+1.  Installing from source (master) would still be the default.  And
any implementations that allowed something different would have to not
disrupt that.  Similar to how we've added new install options in the
paste (source-repositories, tar, etc) and have kept disruptions to a
minimum.



-- 
-- James Slagle
--