Peers vs Members vs Terminology vs Usability

[Stuart Bishop]

On 25 January 2017 at 22:22, James Beedy <jamesbeedy at gmail.com> wrote:

> Trying to use the peers interface to coordinate all units of an
> application to know about each other, I find myself feeling like this
> should be a built in functionality. In other words, "tell me who my peers
> are" shouldn't turn into a giant milestone for every charm who needs to
> know what peers it has (skewed usage of peers here per Juju definition of
> peers). I feel like there are a decent number of charms/applications that
> will end up recreating this functionality independently (or already have),
> to the extent that we should probably think about making this functionality
> more built in/generic. My understanding for what a peer is, is different
> than what Juju defines a peer to be, hence we should think about defining
> some terminology around the term 'peer'. Possibly there is just a need for
> a generic 'members' interface built off the peers interface, which would do
> the coordination and caching bits, and make some basic information
> available to each member about its complimentary members?
>
> Thoughts?
>

If you want to build this API, it could be done as a charm layer. If that
sounds too heavy weight just for this, it could be squeezed into
layer:coordinator with just a little bit of squinting. It also might be
doable as an interface, so all charms declaring a peer relation using the
'members' interface name get to share your implementation, which I think
matches what you are suggesting. For it to be built into Juju, I think you
would need a more concrete suggestion and a rationale on why it is better
built in as opposed to being pulled into the charm using a reactive layer
or interface or even just a Python library in the wheelhouse.

I personally would not have found it useful, as when I've needed a peer
relation I've needed a lot more than just knowing who the peers are and
their addresses.  Maybe I should write less complex charms :)

You might find that charmhelpers.context gives you enough to keep you happy
- context.Relations().peer gives you a dictionary of peer -> relation data,
and context.Relations().peer.local is a dictionary of the local peer
relation data that you can update (but note that the design has a bug in
it, as it assumes there is a single peer relation while in reality charms
can have multiple peer relations. You will consistently get the same peer
relation, but it might not be the one you expect).


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