We need a relation identifier for hooks

[Gustavo Niemeyer]

There are several use cases which would benefit from having a unique identifier per relation. Today we can tell what are the service name, the relation name, and list all the units participating within the relation, but we can't determine an unique identifier for the given relation.

For the implementation, I suggest we use identifiers such as "relation-3", which is built upon the internal id for the given relation (relation-0000000003).

This bug is related to bug #767195, except the latter is about iterating on the relations, while this one is simply about enabling the hook to know what's the relation it's executing for. As such, #767195 should be addressed afterwards.

[Gustavo Niemeyer (niemeyer)]

Clint has another use case for this, described in bug #791042:

"""
While working on the mysql formula, I needed a way to record the fact that a relation had been broken, so that when it was re-added, the code path would be slightly different since the database already existed.

Unfortunately, the environment doesn't seem to contain an indicator as to which relationship is broken. ENSEMBLE_RELATION only tells me which of my relations are being broken, but not what remote service has been unrelated.

The workaround is to run 'relation-list' which seems to somehow know which relationship is being broken and only return the members of it. Whatever it uses to know that, should be exposed to the hook in the environment.
"""

[Kapil Thangavelu (hazmat)]

Excerpts from Gustavo Niemeyer's message of Mon Jun 13 20:17:29 UTC 2011:
> Clint has another use case for this, described in bug #791042:
>
> """
> While working on the mysql formula, I needed a way to record the fact that a relation had been broken, so that when it was re-added, the code path would be slightly different since the database already existed.
>
> Unfortunately, the environment doesn't seem to contain an indicator as
> to which relationship is broken. ENSEMBLE_RELATION only tells me which
> of my relations are being broken, but not what remote service has been
> unrelated.
>
> The workaround is to run 'relation-list' which seems to somehow know which relationship is being broken and only return the members of it. Whatever it uses to know that, should be exposed to the hook in the environment.
> """
>

When the relation is re-added it would be a new relation, so its not clear that relation identifiers will help in that case.

[Gustavo Niemeyer (niemeyer)]

What is being asked for is a relation identifier, specifically. We have two choices: provide a relation identifier that covers the need of re-added relations, or stating that this kind of logic should not be implemented in any way and provide some rationale about why.

One issue I see with the relation identifiers that considers the participating peers is that this list can change, so it will be strange to have an identifier like that while the members can mutate.

Either way, we need to put some further thinking into this issue.

[Clint Byrum (clint-fewbar)]

Excerpts from Gustavo Niemeyer's message of Mon Jun 13 22:11:48 UTC 2011:
> What is being asked for is a relation identifier, specifically. We have
> two choices: provide a relation identifier that covers the need of re-
> added relations, or stating that this kind of logic should not be
> implemented in any way and provide some rationale about why.
>
> One issue I see with the relation identifiers that considers the
> participating peers is that this list can change, so it will be strange
> to have an identifier like that while the members can mutate.
>
> Either way, we need to put some further thinking into this issue.

I think this is ok. As long as the relation-id is available during
all hooks for a relation, then one can very easily map from id to
symbolic name when necessary.

[Gustavo Niemeyer (niemeyer)]

Kapil seems right in that identifying a relation and listing remote members of it are two separate problems. I'll unmark the other bug as a duplicate to ensure we cover both problems.