Immutable configuration best practices for charms

[Stuart Bishop]

On 13 December 2016 at 03:01, Sandor Zeestraten <zandor.z at gmail.com> wrote:


> How are you all dealing with immutable configurations when charming?
>

For now, the best approach I could come up with is to detect the change
(hookenv.config().previous('foo') helps here), and put the unit into a
blocked state until the operator switches the configuration back. Assuming
you are writing a reactive charm, the trick is that this needs to happen
*before* your handlers kick in, and to sys.exit(0) after putting the unit
into a blocked state.

https://git.launchpad.net/postgresql-charm/tree/reactive/postgresql/preflight.py
has the code I use to handle immutable configuration and other config
validation, and uses
https://git.launchpad.net/postgresql-charm/tree/lib/preflight.py to inject
the code early in reactive charm startup (I have an open PR in github to
add a similar builtin feature to reactive)

(Long term, I'm sure we will get richer features. There will always be some
cases where charm code needs to run to validate configration, so maybe some
sort of exit status the config-changed hook can return. Immutable is
simpler than generic validation though, and could probably just be declared
in config.yaml)

-- 
Stuart Bishop <stuart.bishop at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161213/a61ecf9b/attachment.html>