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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
