Comment 1 for bug 1469731

This sounds to me like another reason to implement target/active state on top of "current" state (what we currently show via the relation-* tools).

Active and target states are not *quite* the same, but I think they're both necessary to get a complete picture of what's going on inside your service. In either case, the state is a list of relations and units in those relations (although *not* their settings); the "active" list is composed of the relations that exists and the units that have entered their scope, and the "target" list is the projected relation state in the distant future (so dying relations and units are not shown; but all others are, even if no units have come up yet).

As a first cut, to be fleshed out more in future, it could look something like a `--view` param for `relation-ids` and `relation-list`, allowing values:

  * "current" -- the default value, works as today; usefully consistent lies about current state
  * "target" -- all accessible Alive relations, and all Alive units therein, including self
  * "active" -- all accessible relations, Alive and Dying; and all units, Alive and Dying, currently participating therein

In your particular case, I think you'd just check for your own presence with `--view=target`; if the target state has a happy community of units including yourself, you can expect to be around for a while; if you're not present, you should take the opportunity to hand over any critical state to your siblings; and if nobody's present then everything's shutting down.

I believe the distinction between "target" and "active" is necessary to allow charms to make the right decisions as they scale up and down; I'm very much open to the idea that there should be an analogous `minion-list` command accessible to service leaders, but aware that it's technically redundant with any existing peer relation (i.e. you *could* `relation-list --target $(relation-ids --target my-peer-relation`, but that's squicky).

I also think that we should *not* implement hooks to react to changes in target or active state. Changes to active state would be very close to 1:1 with the existing joined/departed hooks; changes to target state are likewise going to cluster unhelpfully and obscure logic flow; and in any case the active/target state change is merely a preview of an event that is *likely* to happen in the future.

I'm less keen on implementing --view for relation-get, though. The existing view is a weird mixture of current and target anyway, and trying to use it with target-state units or relations will make relation-get much more confusing and no more useful that I can see.

Thoughts?