Open Stack

Clint Byrum said on Wed, Apr 09, 2014 at 01:33:18PM -0700:
> This assumes that we don't want system integrators to contribute to
> TripleO, which is the opposite of how things are. We absolutely do,
> and in fact, that is part of the point of having a program around
> OpenStack deployment. Let's get system integrators into OpenStack's CI
> system and let's get a few of the most important scenarios into the gate
> of OpenStack.
>
> As a system integrator, do you want to say to your customers that you
> start with an unusable set of tools that the community tests individually,
> or do you want to say that you start with the deployment that the
> community tests directly on every commit, and then enhance based on
> individual customer need?

I absolutely do want system integrators to contribute to TripleO. As
you've described the TripleO mission, its entire reason to be is to
provide an integrated OpenStack system. At the same time, I'd like those
contributions not to be muddled in with the core tooling. This
separation makes the base elements far easier to write and also means we
can iterate on the TripleO configuration without necessarily affecting
third-party system integrators.

For example:
 * I produce a 'logstash' element which simply installs + starts that
   service. The configuration is purely what's needed to make it start.
 * I add logstash.conf to the tripleo-compute-config and
   tripleo-controller-config elements, describing how Logstash should be
   configured in the TripleO default deployment.
 * This is tested by TripleO CI.
 * As a service provider, I decide I want a logstash cluster to improve
   scalability. I write my own logstash.conf files and put them in
   mycorp-compute-config and mycorp-controller-config elements. Then I
   rebuild images using both the tripleo-*-config and mycorp-*-config
   elements. This allows me to use the tested TripleO deployment but
   with my own Logstash configuration. Later if I choose I can
   reconfigure other parts of the system, using templates from the
   tripleo-*-config elements as a starting point.

> It is worth noting that Heat has grown the ability to grab a local
> file and inject it into your template at runtime. I think it would
> actually make sense to have os-apply-config enhanced to be able to
> override whole template files based on something like this:
> 
>     resources:
>       server1:
>         metadata:
>           template_overrides:
>             "/etc/nova/nova.conf":
>               get_file [ "my_special_nova.conf.template" ]
> 
> In that, we achieve what you want, but we can do so without rebuilding
> the whole image.

Yeah this is a good enhancement. It'd be more convenient and rule out a
class of gotchas if you could provide a tarball or something rather than
having to individually specify every file.

If we did this then instead of producing tripleo-*-config elements in my
example above, the TripleO default deployment configuration would take
the form of two tarballs for Heat (compute + control). The source for
these could be maintained in a separate repository, EG
tripleo-configuration.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.