Configuration scope

[Michael Nelson]

On Thu, Jan 30, 2014 at 9:45 AM, Stuart Bishop
<stuart.bishop at canonical.com> wrote:
> On Thu, Jan 30, 2014 at 2:55 PM, Michael Nelson
> <michael.nelson at canonical.com> wrote:
>
>>> Not really a question, but just a thought. Would be nice if juju had a scope
>>> added for charm config parameters, i.e. install vs. runtime. Such that it
>>> will make those parameters needed only during deployment of a service
>>> mutable afterwards. Instead of people writing charms silently ignoring such
>>> changes, while juju, on the other hand, accepting and reflecting such
>>> changes as if the had actually happened!
>>
>> Hi Sameer,
>>
>> I've thought about this a few times with the charms I've worked on,
>> and generally it's been possible without too much difficulty to always
>> reflect the changes in the config_changed hook. What are a some
>> examples of install config items that you wouldn't be able to change
>> at runtime? (I've dealt with location of config/log files etc.,
>> versions of installed deps etc., but I'm guessing you've got something
>> trickier).
>
> I have a validate_config() function in the PostgreSQL charm up for
> review. If an invalid config change is requested, it emits an error
> message and causes the hook to fail. The main use case is the
> PostgreSQL major version to deploy. The charm does not support major
> PostgreSQL version upgrades yet, and downgrades are impossible to
> automate (and sometimes just impossible). Your charm does of course
> have to be smart enough to remember its previous state so it can
> detect changes.
>
> If there was someway for my charm to reject config changes rather than
> go into a fail state, that would be nice. I'm not sure it is possible
> though, as 1) we don't want to block a config update on the hooks
> successfully completing 2) if juju rolls back config changes, it needs
> some way of informing the user.

Interesting - so the version of an application is a config option, but
the charm cannot (for whatever reason) handle that changing once
installed. That's a good example, thanks. One idea that might handle
that situation (as well as Sameer's general situation) with a simple
UI:

1) The config.yaml supports a 'const: true' option in the config.yaml,
2) `juju set` will fail with a nice message ("The postgres charm does
not support changing postgres_version once deployed.") if the user
tries to set/change a const config option.

If at a later point, you manage to update the charm so that the
config-changed hook can handle that item changing, the const can be
removed at the same time, so that as soon as people have upgraded the
charm, they can change that config item.

It wouldn't handle a situation where you do allow one type of change,
but not another (like upgrading but not downgrading).