On 27 September 2017 at 10:02, Michael Van Der Beek <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
