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

[Tilman Baumann]

OMG, I went way deep down the rabbit hole.

I had to find charms.reactive.join() to find what the difference of the
scopes really means.

This kept me busy and questioning my sanity for two days:
$ git diff
diff --git a/peers.py b/peers.py
index 976c0ad..93cda29 100644
--- a/peers.py
+++ b/peers.py
@@ -12,7 +12,7 @@ from charms.reactive import scopes


 class PeerDiscovery(RelationBase):
-    scope = scopes.UNIT
+    scope = scopes.SERVICE

     class states(StateList):
         connected = State('{relation_name}.connected')

Sometimes software engineering feels just like a farce. :)


Cheers guys, I hope you where entertained.
 Tilman

On 25.01.2017 16:54, Tilman Baumann wrote:
> On 25.01.2017 15:49, Tilman Baumann wrote:
>> On 25.01.2017 14:24, Tilman Baumann wrote:
>>> On 25.01.2017 13:16, Stuart Bishop wrote:
>>>> On 25 January 2017 at 18:43, Tilman Baumann
>>>
>>>> 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.
>>>
>>> Thanks. That was the breakthrough hint.
>>> [...]
>>> It is either reactive or my charm code.
>>
>> Reactive.
>>
>> Shortened version of my debug interface code:
>>
>> @hook('{peers:peer-discovery}-relation-{joined,changed}')
>> def changed(self):
>>     for conv in self.conversations():
>>         log("JujuInfoClient Conversation.serialize():
>> {}".format(conv.__class__.serialize(conv)))
>>
>> I get:
>> Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
>> 'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
>>
>> I have to go deeper down the rabbit hole. But somehow the Conversations
>> get initialised with bullshit.
>>
>> This would be a example of a correctly initialised conversion.
>> {'scope': 'global', 'units': ['dokuwiki/25'], 'namespace': 'host-system'}
>>
>> I will go bare-metal with charmhelpers and see what I get there...
>>
> 
> charmhelpers.core.hookenv tools seem to perform as expected
> 
> units = related_units()
>   for unit in units:
>     relation_get('private-address', unit)
> 
> I will bodge up a workaround with that now in order to be able to
> deploy. But surely there is something wrong in the way RelationBase gets
> initialised...
>