Configuration scope

[Stuart Bishop]

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.

-- 
Stuart Bishop <stuart.bishop at canonical.com>