normal charm to subordinate charm and now peer relation does not work

[Stuart Bishop]

On 25 January 2017 at 18:43, Tilman Baumann <tilman.baumann at canonical.com>
wrote:

> At this point I'm pretty sure that this is a bug or undocumented feature.
>
>
> The peer relation of a subordinate charm only has one conversation.
> Despite scope being 'global' in metadata.yaml and the RelationBase class
> being scope = scope.UNIT.
>

Relation scopes declared in metadata.yaml have no relation to conversation
scopes, which are a charms.reactive concept.

A relation scope of 'container' means that the relation data is not visible
to other units. The subordinate unit can see the host unit's relation data
and vice versa. Neither can see the relation data on the relation from
their peer units. It looks like a relation with just two end points, rather
than the normal case of one end point for each unit in the two related
services. It gets very, very confusing when one end declares container
scoped and the other end global, so don't do that :)

I don't know why your peer relation (with global scope) starts misbehaving
after you add the container scoped juju-info relation to turn your charm
into a subordinate. It might be helpful to inspect the peer relation with
the hook environment tools to try to narrow down if the problem is with
Juju, charms.reactive, or something else. Using debug-hooks, or 'juju run
--unit foo/0 "relation-ids ssh-peers"' and 'juju run --unit foo/0
"relation-list -r ssh-peers:64"' if you haven't done this before.

One thing to remember is that units join the peer relation one at a time.
So in your peer relation-joined hook, you will only see a single unit. Then
a relation-changed, again with a single unit. And maybe a few more times
with a single unit. Eventually the rest of the units will join, each time
triggering relation-changed one or more times. Maybe your problem is just
that you are looking too soon :)


>
> Either I'm wrong to expect this to work and subordinates are only
> supposed to have container scopes. Then it is a dokufix and should be
> caugt by charm proof.
>

Its fine as far as Juju in concerned. The cs:ntp subordinate has both a
global scoped peer relation and a container scoped juju-info relation (
https://jujucharms.com/ntp). I don't know about the charms.reactive
conversation or relation object, but I can't see why its behaviour would
change once you add the container scoped juju-info relation and think it
more likely that the problem lies elsewhere.


-- 
Stuart Bishop <stuart.bishop at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170125/43bc7f20/attachment.html>