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 > <https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical%27s-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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
