allow charms to decline config changes

[Simon Déziel]

Some configuration changes are not always possible after the initial deployment.

For example, when deploying LXD, one has to decide if standalone or cluster mode is to be used and once set, this cannot be undone. Similarly, the charm accepts a LXD preseed which makes no sense to alter once a unit is deployed.

It would be handy if the charm could simply reject change attempts on certain config keys. Maybe some kind of "modifiable: false" attribute?

[Stéphane Graber (stgraber)]

In discussions with the Juju team, it was mentioned that a few of the potential options for this would be:
 - Separate config validation hook
 - Stronger typing of the config to allow for schema validation
 - Supporting attaching scripts (LUA or the like) to a charm's config which would then be run by the controller to validate the user's config

[John A Meinel (jameinel)]

We are looking to add a few ways to do config validation, one of the ideas is around scriptlets (being able to run validation code inside the juju server in a sandboxed form).
Charms can certainly ignore/set Blocked for a config-changed value, but it doesn't help from the user then seeing 'juju config app' and still seeing the invalid value.