On Thu, Jan 30, 2014 at 2:55 PM, Michael Nelson <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
