On 25 January 2017 at 22:22, James Beedy <jamesbe...@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.bis...@canonical.com>
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
