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
