How should we change default config values in charms?

Simon Davy bloodearnest at gmail.com
Mon Aug 17 10:03:30 UTC 2015


On 16 August 2015 at 19:41, Mark Shuttleworth <mark at ubuntu.com> wrote:
> On 14/08/15 04:56, Stuart Bishop wrote:
>> I've discussed similar things with regard to the PostgreSQL charm and
>> autotuning, with the decision being that charm defaults should be set
>> so things 'just work' in a development environment.
>
> Yes, charm defaults should be efficient for rapid iteration and development.
>
> Iteration and development scenarios are, as Stub points out, orders of
> magnitude more common than production scenarios.

Interesting. We have been defaulting to production settings, as we
don't want to deploy an incorrect/unsafe config in production by
omission, especially security related config.

I see the motivation of making it easier for people to get going
though, but IMO, from an operational standpoint, development defaults
are concerning.

I think maybe there is a distinction between performance defaults and
security defaults, and defaults can be dev on the former, and
production on the latter, maybe?

> In future, we might designate whole environments as dev, test or
> production, so that charms could auto-tune differently.

Sounds good, we do something similar manually.

Thanks

-- 
Simon



More information about the Juju mailing list