Open Stack

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.

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

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.

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

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.