A charm’s metadata.yaml relations: section contains a little-used feature, a flag to signal whether relation is optional. It’s probably unused because it doesn’t actually do anything.
I wonder if it would make sense for Juju to enforce this at deploy time. It would simplify things for new users because the application would immediately become blocked and the error message could be consistent.
To avoid breaking current behaviour, we could change the default to optional: true.
It’s a nice idea to simplify the job of the charm, however it has issues. There should only be one source of truth setting unit status - the charm. The 4 status values - waiting, blocked, maintenance, active - are all reflective of the state of the workload as managed by the charm. The charm knows if required relations are joined or not (via hooks). Having another entity (the agent) attempt to also set the unit status value would lead to unfortunate race conditions. Juju starts off by setting the status of the unit as waiting, and thereafter once the unit agent has started, the charm is responsible from that point on.
This would still be the charm’s call, it’s the charm’s metadata.yaml file that would be driving the behaviour.
Starting with the waiting state is already a race condition. We can improve on the status quo for new users by not defaulting to a status code that implies that things will resolve without further intervention.
