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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev