Enforce 'optional: false' in metadata.yaml

[Stuart Bishop]

metadata.yaml allows a charm to specify 'optional: false' in its metadata.yaml file. This is not enforced by Juju (and documented as such). Now we have service status, we could keep the units in 'blocked' status until all required relations have been added.

This would improve visibility to end users, as they can see why things are blocked and how to proceed.

Note that charms cannot do this correctly themselves. For a charm to encode this logic, the best it can do is to introspect its relations in its config-changed, *-relation-joined and *-relation-broken hooks and set the blocked status there. This isn't technically correct, as the charm doesn't know if the relation needs to be added or if it just hasn't been joined yet. It has no way of knowing if the status should be waiting (waiting for the relation hooks to run), or blocked (waiting for the relation to be added by the operator). Blocked is the best choice for this work around, as the incorrect status will be fixed automatically once the hooks have run, as opposed to leaving the service in a waiting state indefinitely and telling the user things are progressing when they have actually stalled.

[Marco Ceppi (marcoceppi)]

I don't think this should be enforced, with status-set in 1.24 charm logic can much better convey this to it's users.

[Stuart Bishop (stub)]

@marcoceppi With status-set, before you can tell if the relation has been added or not (eg. in your install hook) you have the choice between using the waiting or blocked status. Neither choice is correct. waiting is incorrect if the relation has not been added, as the charm is actually blocked. blocked is incorrect if the relation has been added but the hooks not yet run, as the status is actually waiting and setting blocked will alarm the user (hey! I need attention! Oh, never mind... I'm just a little slow today). The status should indicate meaningful transitions to the end user, and not flap.

An easy fix for this may be juju overriding the units status or using the agent status so blocked is displayed at the correct time to the user, rather than requiring the charm to predict the future or lie.

[Stuart Bishop (stub)]

... or revise the docs to indicate that blocked means 'potentially requires user intervention' and might be a transitory state, rather than 'requires user intervention' that will not change without assistance.