Add schema to config.yaml to manage configuration that can only be set at deployment

[Drew Freiberger]

Several charms have options that are not configurable after deployment of a charm.

Examples include:
 cs:cassandra "rack" and "datacenter" cannot be changed after deployment
 cs:swift-proxy "partition-power" cannot be changed after rings have been built
 cs:rabbitmq-server "ceph-osd-replication-count" cannot be changed after the pool has been created

Handling the case of these sorts of options changing after deployment requires code to handle the configuration status within the charm code itself instead of being able to pass this configuration management upstream to juju to handle at the operator interface layer.

It would be helpful if juju could implement an additional config schema component that determines if an option should be immutable to reduce the amount of overhead needed during charm development.

[Harry Pidcock (hpidcock)]

This seems like a decent idea. I'm trying to picture how this might look from the perspective of a user deploying a charm with immutable config fields.

I would imagine these fields are generally required fields and perhaps forcing the deployer to make an explicit decision to set them is ideal.

Charmers would probably just set it within their config.yaml. Many possibilities how we could do this.

# config.yaml
options:
  datacenter:
    type: string
    description: Which datacenter this deployment belongs.
    immutable: true

# config2.yaml
options:
  datacenter:
    type: string
    description: Which datacenter this deployment belongs.
    constant: true

# config3.yaml
options:
  datacenter:
    type: conststring
    description: Which datacenter this deployment belongs.

[Drew Freiberger (afreiberger)]

I can understand the idea behind wanting to require the user to specify the value, however, I think keeping the option for the charm developer to provide an opinionated default is important for continuity of the products already available. Maybe a warning provided by the UI during deployment that immutable/constant variables are not being explicitly set would be a good mitigating factor rather than outright requiring the setting of the variables by the operator.

[Amanda Hager Lopes de Andrade Katz (amandahla)]

Hi, we have a similar case where we need to prevent a configuration field to be changed.
Scenario: Synapse server name cannot be changed once is set.
Reference:
https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#server_name