system_email should be configurable

[Peter Sabaini]

There should be an option for choosing system_email, as the default doesn't always work. Eg. in the default trusty postfix config:

mail from:noreply@10.x.x.x
501 5.1.7 Bad sender address syntax

landscape-server;revno=227

[Free Ekanayaka (free.ekanayaka)]

The charm has a Juju action called "bootstrap" (see actions.yaml) that lets you create the first admin. Would it be fine to add a system_email optional parameter to this action?

A config-level option wouldn't make too much sense, since there's now way to keep it in sync with the actual setting in Landscape (which you can always change via the UI).

[Peter Sabaini (peter-sabaini)]

I wonder if there's really no API to set this parameter?

For maintenance and reproducable builds we try to capture as much as possible of the configuration of a system in version control, and having a one-off action run required doesn't fit too well with this.

[Adam Dyess (addyess)]

If i understand this bug correctly, this would be nice as a charm config to set the 'System email address' which is settable on the Landscape Web UI under "Settings" for the Landscape Administrator.

This email address seems to default to `<email address hidden>` if unset. I don't understand the relation to the bootstrap action. I don't believe this is to set the 'administrator's email"

[Simon Poirier (simpoir)]

It's about setting a charm config which would would push new values when changed.

The point about the bootstrap is the concern that a user could try to change the value in the UI while it's set differently on the charm. I don't think that's an issue worth the confusion of having some config only applied on bootstrap and not changeable later. So my intent is to have this be a proper config.

[Drew Freiberger (afreiberger)]

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.

[Simon Poirier (simpoir)]

I had an unmerged branch lying around doing exactly that (and some of the configs from #1682105 & #1867383).
It requires us backporting rev 11387 of lp:landscape/trunk to lp:landscape/19.10 in order for it to actually do something.

I'll set an MP up.