On 2011-04-29T10:36:54, Andrew Beekhof <and...@beekhof.net> wrote:
> > As I understood it we had essentially reached consensus in Boston that
> > CIB replication would best be achieved by a pair of complementary
> > resource agents. I don't think we had a name then, but I'll call them
> > Publisher and Subscriber for the purposes of this discussion.
> >
> > The idea would be that Publisher exposes the <configuration/> section of
> > the CIB via a network daemon, preferably one that uses encryption.
> > Suppose this is something like lighttpd with SSL/TLS support.
>
> I can also offer a Matahari (QMF) agent.
> The new Luci is going to be using it to get the config off remote
> machines anyway.
A pull model works for me.
> > This would be a simple primitive running exactly once in the
> > Pacemaker cluster, and only if that cluster holds the "ticket".
Yeah, so logically it would make sense to collocate it with - or
incorporate it into - the Cluster Ticket Registry, since the same is
true for that.
> > Subscriber would be the only resource (besides STONITH resources and
> > Slaves of master/slave sets) that can be active in a cluster that does
> > not hold the "ticket".
> or:
> colocation $ticket -inf
Well, the CTR needs to be active once per cluster anyway, and it knows
which site is the current "master" for a given ticket (or if it isn't
itself).
Maybe this component of the CTR can just switch state along with that
too?
Regards,
Lars
--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
