config.yaml is key to the juju model.
Currently, Juju would rightfully reject invalid config options based on the type: string, int, float and boolean (https://juju.is/docs/sdk/config).
However, in some cases, config option validation can only be done in charm code:
- string option is limited to some values;
- a numeric option has a range (e.g. percentage is a float 0-100);
- etc.
Currently, charm code cannot "argue" with a juju config entry: it must act on it regardless if it is deemed valid or not in the context of the charm. Current practice is to set the status to "blocked" and perhaps stop the pebble service, or let the service run (but then it would constitute an unrightful deviation from the juju model).
It would be a smoother charm dev and user experience if config options could be rejected so the only thing charm code would need to do is validate and reject, instead of being forced to accept and act on it.
Hi, Leon
Sounds reasonable,
I'll mark it as a feature request, to be able to discuss it in future cycle roadmap cycles.
Thank you.