pyjuju

We need a relation identifier for hooks

Bug #791370 reported by Gustavo Niemeyer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pyjuju
Confirmed
Medium
Unassigned
pyjuju florence

Bug Description

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)
Changed in ensemble:
importance: Undecided → Medium
status: New → Confirmed
milestone: none → dublin
assignee: nobody → Benjamin Saller (bcsaller)
Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

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.
"""

Revision history for this message
Kapil Thangavelu (hazmat) wrote : Re: [Bug 791370] Re: We need a relation identifier for hooks

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.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

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.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

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.

Kapil Thangavelu (hazmat)
Changed in ensemble:
milestone: dublin → eureka
Kapil Thangavelu (hazmat)
Changed in juju:
assignee: Benjamin Saller (bcsaller) → nobody
milestone: eureka → florence
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.