Open Stack

Excerpts from Alexis Lee's message of 2014-04-09 06:44:20 -0700:
> Robert Collins said on Wed, Apr 09, 2014 at 01:58:59AM +1200:
> > I like this - something like
> > 
> > nova:
> >   config:
> >     - section: default
> >       values:
> >         - option: 'compute_manager'
> >           value: 'ironic.nova.compute.manager.ClusterComputeManager'
> >     - section: cells
> >       values:
> >         - option: 'driver'
> >           value: nova.cells.rpc_driver.CellsRPCDriver
> > 
> > 
> > should be able to represent most? all (it can handle repeating items)
> > oslo.config settings and render it easily:
> > 
> > {{#config}}
> > {{#comment}} repeats for each section {{/comment}}
> > [{{section}}]
> > {{#values}}
> > {{option}}={{value}}
> > {{/values}}
> > {{/config}}
> 
> Hello,
> 
> I've gone some distance down this road:
>   https://review.openstack.org/#/c/83353/6/elements/nova/os-apply-config/etc/nova/log.conf
>   https://review.openstack.org/#/c/83422/6/logstash-source.yaml
> 
> I wouldn't call the result - encoding a complete config file into Heat
> metadata - pretty. And this isn't completely genericised either.
> 

I find your templates pretty easy to read. Mustache was chosen because it
has almost no logic, and thus is _extremely_ easy to follow and predict.

> It'd be much better if TripleO image elements focused on installing and
> starting services and allowed system integrators to define the
> configuration. In one place, in plain text files, the UNIX way. I've
> appended my proposal to Rob's etherpad here:
>   https://etherpad.openstack.org/p/tripleo-config-passthrough
> 

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?

> Soon-to-be outdated copy appended here:
> --------------------------------------------------------------------------------
> 
> Hi Rob, I have some serious concerns about the above approaches. For the
> sake of argument, let's suppose we want to write a file that looks like
> a Heat template. How would you write a Mustache template that handles
> that level of nesting? Even if you accomplish that, how readable do you
> think the metadata to fill out that template would look?
> 
> I see the system integration process emerging like this:
>     * Figure out what files you want + what you want in them
>     * Slice and dice that into metadata
>     * Write some fairly complicated templates to reconstitute the metadata
>     * Get out more or less what you started with
> 
> I'd like to propose an alternative method where Heat and TripleO barely
> touch the config. The system integrator writes an image element per
> node-flavour, EG "mycorp-compute-config". If they choose, they could
> write more (EG for specific hardware) limited only by their
> devtest-equivalent's ability to allocate those. This element contains a
> 99-os-apply-config directory, the templates from which overwrite any
> templates from normal os-apply-config directories in other elements.
> os-apply-config/install.d/99-install-config-templates will need to be
> patched for this to be possible, but this is very little work in
> comparison to the alternatives. I could also support simply an
> os-apply-config.override directory, if a full numbered set of dirs seems
> overkill, but in this case normal elements would have to be forbidden
> from using it (and people being as they are, someone would). The
> templates in that directory are 99% plain config files, laid out in a
> single filesystem structure exactly as the system integrator wants them.
> The only templated values which need to be supplied by Heat are those
> which vary per-instance.
>

So one reason I'd rather see overrides done generically as heat
parameters/metadata/etc. is that it may not be entirely clear when a
user needs to override from a default, and having to distribute a new
image to do that is not necessarily the best user experience, especially
if one is "tinkering".

> If we do this, tripleo-image-elements should focus on installing and
> starting services. They should only include a minimal viable
> configuration for demo purposes. This should greatly reduce the amount
> of work required to produce a new element. Also the number of Heat
> parameters used by any element (only per-instance would be necessary,
> anything further is a convenience).
>

OpenStack is not for demo purposes, it is for production usage. There
is no reason we cannot and should not build a deployment that can be
used directly in the most common configuration, and then open that up to
more and more users through configuration options and topology options.

> Some usecases where this approach is superior:
>     * Files where order is important, EG squid.conf
>     * Files which multiple elements want to touch, EG nova.conf
>     * When the system integrator wants to add config unforeseen by the
>       appropriate element or where using an element would be
>       heavyweight. EG to configure the MOTD or add a global vimrc.
>     * Easy to add hardware-specific configuration
> 
> Final thoughts - the "mycorp-compute-config" element might need to do a
> bit of chmod + chown'ing as well as just providing 99-os-apply-config.
> 
> If OpenStack wants to provide a complete off-the-shelf configured
> solution, we could provide a system integrator element which expresses
> OpenStack opinion on what that solution should look like. In fact we
> could provide several, suitable to different scales.
> 

This is exactly what we're doing. We're just suggesting exposing
variations in the Heat templates, rather than in the elements. 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.