Re: Immutable configuration best practices for charms

2016-12-13 Thread Stuart Bishop 
On 13 December 2016 at 03:01, Sandor Zeestraten  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 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Immutable configuration best practices for charms

2016-12-12 Thread Mark Shuttleworth 
On 12/12/16 12:01, Sandor Zeestraten wrote:
> How are you all dealing with immutable configurations when charming?
> I know that the best practices[1] say that charm configurations should
> not be immutable, however not all applications are created equally
> (see for example [2]).
> Anyone have any thoughts or ideas on how to deal with these issues
> where you have to lock down something when deploying?
>
> [1]
> https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical's-infrastructure-team
> 
> [2] https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1623679
>

The thinking is that we should declaratively identify config elements
which are immutable (i.e. cannot be changed after deploy). At the
moment, we are digging into config patterns at the single-node level
with snaps, and then we want to bring that thinking back to Juju for
"config 2.0" on applications at the cluster level.

Mark

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Immutable configuration best practices for charms

2016-12-12 Thread Sandor Zeestraten 
Hey folks,

How are you all dealing with immutable configurations when charming?
I know that the best practices[1] say that charm configurations should not
be immutable, however not all applications are created equally (see for
example [2]).
Anyone have any thoughts or ideas on how to deal with these issues where
you have to lock down something when deploying?

[1]
https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical's-infrastructure-team
[2] https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1623679

Thanks,
Sandor
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju