Comment 5 for bug 1499686

I agree with @simpoir that this should be a charm config (not bootstrap option).

Charm configs commonly change settings that are also available to an administrator to also tweak in a UI. Ultimately, it's the responsibility of the Juju operator to know what settings are available to be managed via Juju before setting application configs by hand. The Juju-exposed configs also address the re-deployable aspect that @peter-sabaini was mentioning.

We address this in a few ways, such as for system config files where we can drop a '# this file managed by juju' entry and when we use good practices naming input/output/dashboard configurations managed by juju with a [juju] tag or pre-pended name in charms like Grafana and Graylog to reduce operator confusion and collision of UI vs juju managed bits.

While it's possible that the UI could get ahead of the juju configuration, the charm should be able to gracefully handle updating the configuration back to the requested juju config if config-changed or upgrade-charm is called, reverting any setting that was done by an admin in the UI.

I don't think we would need to burden the charm with handling the edge-case of an admin modifying the setting in the UI to something other than what is set in the Juju charm config, but it could be handled such that, if the charm config is left blank, the setting in the UI will rule, which could allow for maintaining the current settings that have been made manually on current deployments when we upgrade the charm to one that supports setting this option.