Hi, it became clear that my charm which was so far standalone (to be installed together with other charms on the same machine) should better be subordinate. A few obvious changes where required regarding the life-cycle of the charm. No big deal. https://github.com/tbaumann/iptables-peer-ssh
However, suddenly the peer relation is behaving very oddly. I'm only seeing one (arbitrary) peer unit in the relation. This method only does one loop iteration and returns only one value. def units(self): hosts = [] for conv in self.conversations(): hosts.append(conv.get_remote('private-address')) return hosts The class has scope.UNIT scope. class PeerDiscovery(RelationBase): scope = scopes.UNIT metadata.yaml specifies global scope for the peer relation. peers: ssh-peers: interface: peer-discovery scope: global requires: host-system: interface: juju-info scope: container Any idea what could be happening here. I suspect something with the scopes. But they are now all set explicitly. Any changes in implicit behavior should not affect this. Am I expecting something from subordinate charms which they can not provide? The ssh-peers-relation-* hooks are still called when a unit joins or leaves. But somehow it's information is not added to the conversation. Or rather, I think it replaces actually the currently visible single entry in there. Here is the as of yet unpublished interface code. https://github.com/tbaumann/charm-interface-peer-discovery -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju