config.yaml should have enum type

Adding this to juju-core, as enums are still being requested for juju configuration

Conceptually, could look like this:

options:
    tuning:
        default: 'safe'
        type: enum
        description: 'Tuning level for service'
        selection:
            unsafe: 'Fastest without regards to data'
            fast: 'Balanced saftey/speed’
            safe: 'Data Safe'

Selection defines the enumerated keys, each key is set to a human readable description. This would be rendered in the Juju GUI as a dropdown using the values of each selection key as the value which is displayed to the user.

Given that this is behavior that ought to cross core/gui/jaas/ecosystem it would be good for Rick Harding to weigh in, and ideally we get this prioritized this cycle, with a spec, and cross-team effort to get this done.

This would be part of the config schema work that has been talked about but not planned or prioritized. There's a goal to move all config to the same jsonschema mechanism that actions uses which is why it allows more advanced types to be used.

We need to build the case to work on this over other priorities in the next cycle. Knowing more about the pain points will help us build that case.

https://github.com/juju/jsonschema/schema was added 4 months ago and supports enum types.

Marking is as Fix Committed but adding it to current development milestone - 2.1-rc1 as all others are already released and are no longer available.

Let me check if it is used everywhere.

This is used in interactive bootstrap and as an input to add-cloud.

Looked at the bug again :)

We have not moved config.yaml as was intended according to comment #4. We have just introduced added jsonschema library that has enum support for other Juju functionality as described above.

I'll leave this bug as Medium. This work still needs to take place

This bug needs revisiting.

There are many charms that have to manage internal validation of enum-type config.yaml variables that should be handled at the juju client/bundle/validation layer instead of having to re-code enum validation in each charm.

See bug https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1942918 as an example of how operators can easily shoot themselves in the foot without these safety measures.

Having the schema validation for enum-type variables at the client end can prevent config-changed hooks from erroring and causing outage of juju-managed applications.

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

I can't update the importance field but from our perspective nothing has changed, this bug should still be marked as medium priority.