Open Stack

Hi,

I was recently looking at how to support custom configuration that relies on
post deployment setup. Specifically about how to support designate optional
configuration for the sink service. The configuration lives on the application
units but needs the domain id of the designate domain that the records should
be created in. This domain is created post-deployment and, obviously, the uuid
of the domain will change on each deployment.

I would like to propose doing this through post deployment actions and I think
the general approach will be useful across multiple charms. The charm can have
pre-defined custom config which can be enabled through an action. The action
parameters also provide an additional context for rendering the template which
includes data from the post deployment setup. This approach does not allow
arbitrary config to be injected, instead it allows predefined config to
activated via actions.

To illustrate the approach I'll stick with the designate example:

1) Cloud deployed and administrator sets up new domain
2) Administrator runs a new add-sink-config action and passes the domain-id
   and sink config file name.
3) The lead unit updates a map in the leader db which lists additional config
   files and corresponding context derived from the action options. Each
   set of config stores its options in its own namespace.
4) The lead unit then triggers config to be rerendered locally.
5) Non-lead units are triggered by the leader-settings-changed hook and also
   rerender their configs.

Here is a prototype for the designate charm: https://goo.gl/CJj2Rh

Any thoughts, objections, you-haven;t-thought-of-this' gratefully recieved
Liam