Re: Peers vs Members vs Terminology vs Usability

On 30 January 2017 at 02:55, James Beedy wrote: > 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

Re: Peers vs Members vs Terminology vs Usability

> > ... > > - 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

Re: Peers vs Members vs Terminology vs Usability

On 25 January 2017 at 22:22, James Beedy 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"

Re: Peers vs Members vs Terminology vs Usability

On 25 January 2017 at 22:22, James Beedy 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"

Peers vs Members vs Terminology vs Usability

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

Peers vs Members vs Terminology vs Usability

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