On Tue, Nov 18, 2014 at 3:19 AM, Kapil Thangavelu <kapil.thangav...@canonical.com> wrote: > > status per future impl helps, as does explicitly marking units.. but pending > cluster count is a missing and important property to properly establish > quorum in a peer rel from one to n that is only resolved by knowing recorded > units count for a svc. > > cheers, > > Kapil
I strongly agree with Kapil on the importance of have a cluster count for determining quorum in peer relations, also for leader election. We have experienced problems determining cluster quorum on different official charms ( i.e. mongodb, openstack charms ). There are a plenty amount of hacks for 'solving this' , getting the first deployed peer unit as the master based on the unit id, choosing a random one, or like the case of 'hacluster' charm ( which is the base for all our HA charms ) by using a prefixed parameter ( cluster_count ). The desired fix would be to have the number of how many peer relations the unit has globally , no matter of the state ( started, stop, building , etc) With that we can solve most of the initial quorum issues. -- Jorge Niedbalski R. Software Sustaining Engineer CTS - Engineering Team gpg:0x3DA28544, irc: niedbalski -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev