normal charm to subordinate charm and now peer relation does not work
Tilman Baumann
tilman.baumann at canonical.com
Wed Jan 25 15:54:14 UTC 2017
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...
More information about the Juju
mailing list