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? > Stuart, Thanks for the response. After thinking about this more, I feel like what I'm really after is an api to expose the relational data for the current units of an application. Your suggestions are great. I am, and have been for a while looking into both creating a peers interface and layer as well - and am just a bit stumped I guess. @chuckbutler has given me some good examples from his etcd layer and interface of how I might construct this, which are on par with what you are suggesting (I think). Etcd, alongside many other charms (that need to know their peers) could of been a smoother experience for the author, had this functionality already existed. I'm thinking its something I'm going to need quite a bit moving forward, so I appreciate the input here (it looks like you have already created this functionality - ha). I've been using elasticsearch-base as a playground for developing this, as (for the moment) the units of the elasticsearch-base charm only need to know what units of an application exist when a unit joins or departs the relationship so it can update elasticsearch.yml and restart elasticsearch. I started out with a working implementation where all units of the application could know about eachother by updating the unitdata with their ip when they join, following which all units of the application grab the new unit data and update their configs. Where I am hitting contention is trying update the unitdata cache with the current data for all existing members when a unit departs the relationship. Basically a diff of what it was before. It sounds like what you've suggested, using context.Relations().peer might be the pre-existing functionality that you've written that I can use to derive the functionality I'm looking for. Heres what I've got going on now using the leader to do the coordinating to some degree... I feel like its becoming a hack fest though ... possibly you could take a look? https://github.com/jamesbeedy/juju-layer-elasticsearch-base/blob/use_master_for_member_add/reactive/elasticsearch_base.py#L126 <https://github.com/jamesbeedy/juju-layer-elasticsearch-base/blob/use_master_for_member_add/reactive/elasticsearch_base.py> https://github.com/jamesbeedy/interface-elasticsearch/blob/peers_testing/peers.py Inline responses below 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. - Thanks. I'll look into this. 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. - This sounds legitimate too, and is something I've been experimenting with. 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. - These are great ideas, and sound like a great way to move forward with this. - Possibly not "built into into Juju", but more of "built in" from a charm author/Juju user perspective. As a user of the reactive framework (and Juju), I want to use these tools to best support operations in my organization. In a fast paced environment, end users don't always have the opportunity to spend the time it takes to procure robust, extended functionality, instead, it becomes more or less an "I want to us these tools to get the job done" use case. This is something I struggle with as a user, because I need to be curating charms from a higher level to facilitate increased iteration, otherwise someone will just write a dockerfile that gets deployed, and becomes something that is more difficult to swap out with a charm later on (purely my job to stop this from happening). 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. - To this extent, possibly it would of made the path to what you were trying to accomplish a more pleasant experience if you had an api to access to the relational data for all of the units of its application type, and were able to just focus on what you were trying to do (looks like you have created context.Relations() specifically for this purpose)? Maybe I should write less complex charms :) - You're charms are (what I feel to be) really great examples of usage of the reactive framework. I use the postgresql charm in 9/10 apps I have deployed - it has become a critical piece of infrastructure in my application stack. It's use and lifecycle are very practical, whilst robust in features and functionality. I will recommend it to anyone wanting to get started using Juju, the same as I would recommend it to those looking to deploy postgres in production. The postgresql release cadence, support of current features, and charm-upgrade experience, are all super on point too. I want to take a moment to thank you for this. You might find that charmhelpers.context gives you enough to keep you happy - context.Relations().peer gives you a dictionary of peer -> relation data, - This is very possibly exactly what I'm looking for. Does context.Relations().peer give you access to the relational data of your 'peer' in the context of Juju - such that a unit's only peer is the leader, and the leaders peers are all members that are not the leader? Or does this return relation data for all peers of the relation? and context.Relations().peer.local is a dictionary of the local peer relation data that you can update - Update with the information that context.Relations().peer returns? How is this different/better/worse then using leader to store the data, or unit data even? Because its data on the relation, which makes it fit the reactive model better/less cluttered? - I seem to be hitting an issue with layer leadership where only the leader is able to set data to the leader. Is this intended by design, or is this (what appears to be) a bug? (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). - Uggg, possibly I've already been hitting this. Thanks, James
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
