CTDB API

[tridge at samba.org]

Alexander,

 > int ctdb_set_conditional(struct ctdb_context *ctdb, ctdb_conditional_fn
 > fn, uint32_t condition_id, void *private);
 > 
 >   - this function has to be executed on all dispatchers, with the same
 > set of conditional functions and IDs as all conditions have to be the
 > same on all DMASTERs and all nodes are potential DMASTERs.

Something just occurred to me about this API that I think is worth
mentioning. It puts a fairly tight constraint on the architecture we
use for clustered Samba.

The architecture I was imagining was:

  1 or more smbd processes (as per normal Samba)
  1 dispatcher daemon process

each of the smbd processes would talk to the dispatcher daemon via a
unix domain socket (probably a dgram socket). The dispatcher daemon
would be the main 'ctdb' daemon, and would talk to the cluster.

This is all fine, except that ctdb_set_conditional() implies passing a
function pointer from the smbd process to the dispatcher daemon. This
is needed as the dispatcher daemon acts as the DMASTER/LMASTER in the
cluster, and the function needs to execute on the DMASTER.

This means that in practical terms the dispatcher daemon has to be the
same executable as smbd, a forked child. We can't have a standalone
ctdb_daemon executable and meaningfully pass a function pointer from
smbd to that daemon.

Alternatively, we could make the functions that can be passed to the
dispatcher daemon fixed at compile time, and have a table of them. I
don't like this as much as the functions being executed really are
logically part of smbd.

Anyway, this doesn't really affect the API, it just affects how the
processes relate to each other. I didn't realise this until I started
coding the ctdb daemon and realised it really needed to be a library
linked into smbd that forks a process. In the Samba4 world it will be
a smbd task with the single process model (much like the ldap and nbt
servers are now). In the Samba3 world it will be more like the async
DNS child of nmbd, or the 'dual daemon' model in winbindd.

We can still develop it separately from smbd, but it will need to be
fairly tightly integrated into smbd once we move outside the ctdb test
environment.

Cheers, Tridge