[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)

Harald Welte laforge at netfilter.org
Mon Sep 27 15:39:05 CEST 2004

On Mon, Sep 27, 2004 at 09:07:53AM -0400, jamal wrote:
> I think it would be better to separate the election process (who is
> master) from the syncing code. For some reason i thought this separation
> was there (and that all you had to do was bag some /proc entry). 
> i.e if VRRP is the code that makes the decision that it wants you to be
> the master, thats how you become master. If someothericandohabetter (eg
> forCES) protocol wants you to be the master, thats how you become the
> master. There is no point in inventing a new HA scheme.
> And if you do it should probably be in user space (there is no
> perfomance issues with it) i.e its such a protocol (in user space) that 
> should tell your syncing code to send syncs or not.
> Unless i missed something fundamental.

I totally agree with you, jamal.  And in fact this is exactly what we
have.  You tell one box it is master, and it becomes master.   You tell
a box it is slave, and it becomes slave.

There is just a minor addition in one case, where we want to safeguard
against a (currently) invalid mode of operation.  As soon as ct_sync
supports multiple master, this safeguard will certainly be removed.

But for the current code, unless somebody shows to me that it severely
limits some use of ct_sync, or it causes practical problems, I don't see
why we should remove this safeguard.

> cheers,
> jamal

- Harald Welte <laforge at netfilter.org>             http://www.netfilter.org/
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20040927/28f18f92/attachment.bin

More information about the netfilter-devel mailing list