Rejection of peer join.

[Stuart Bishop]

On 27 September 2017 at 10:02, Michael Van Der Beek
<michael.van at antlabs.com> wrote:
> Hi All,
>
> I was thinking about a charm, that for peer relationship, supports only two
> instances to form a peer.
>
> What would be the correct response to reject a 3rd instance trying to join
> gracefully so that juju doesn’t complain of a failed setup?
>
> Exit 1 this will sure cause problems. Exit 0 but then juju doesn’t know that
> the relationship is not set.

Set the workload status  of the unit that should not join to 'blocked'
with a message explaining the problem, and Exit 0 (using the
'status-set' hook environment tool, or hookenv.status_set() in
charm-helpers). The live peers should just ignore the third unit.

If you do it right, it would be possible to add a third unit, then
remove one of the live pair, and have everything migrate across to the
new unit with only a small period of time without redundancy.


> The idea is that I want to do failover within a pair of instances.
>
> I have a radius load balancer that will split packets based on a modulus of
> same framedip (ip of client) or mac address or something.
>
> So each pair of radius would only hold sessions related to that modulus
> result. So if I do modulus 4, I’ll have 4 pairs of instances.
>
> I’m not sure if running each pair (active-standby) support 1000tps is viable
> up to a million sessions.

You may not be sure, but maybe the person who is using your charm is?
Or wants to test it? If it is no more effort, I'd suggest supporting
an arbitrary number of units rather than just one or two. It could
also provide a mechanism to migrate the Juju application to new units
without ever losing redundancy by allowing the operator to bring a
third unit online, wait for it to get in sync, and then drop one of
the original units.

-- 
Stuart Bishop <stuart.bishop at canonical.com>