[RFC] Strategies for CTDB integration into Samba

[Michael Adam]

On 2014-10-27 at 16:19 +1100, Amitay Isaacs wrote:
> On Sat, Oct 25, 2014 at 12:23 AM, Michael Adam <obnox at samba.org> wrote:
> >
> > What is going on:
> > ================
> >
> > - Selftest needs to be augmented to run the samba-ctdb stack.
> >   ==> I need to revive, finish and propose my
> >   clustered-samba selftest branches.
> >
> >
> If we manage to setup cluster as part of selftest, then we will be able to
> run ctdb's cluster tests.

Here are my branches (patches are really WIP!) that I want
to revive:

https://git.samba.org/?p=obnox/samba/samba-obnox.git;a=shortlog;h=refs/heads/master-clusteredmember-1node

https://git.samba.org/?p=obnox/samba/samba-obnox.git;a=shortlog;h=refs/heads/master-clusteredmember-3node


> Few more things that Martin and I are working on.
> 
>  - Improve the ctdb protocol from current "structs on wire" approach to
> proper protocol definition and automatic generation of serialization
> routines.
> 
>  - To avoid changing the protocol in two implementations (source3
> ctdbd_conn/dbwrap and ctdb client/server), abstract the protocol and
> provide ctdb api for file server code.  This resurrects the idea of
> libctdb, but focuses mainly on providing marshaling/unmarshaling routines,
> rather that providing a complete API for ctdb.  Thanks to Volker for making
> valuable suggestions to avoid memory allocations in the marshaling code.
> The wip code is available in my ctdb-libctdb branch.

Great!
I will try to have a look into this.

>  - Split some of the ctdb functionality in separate daemons.  This requires
> a messaging framework.  Adopt new datagram messaging in an attempt to unify
> messaging across samba and ctdb daemons.
> 
> 
> > The question is now: Where do we want to go?
> > ============================================
> >
> > - to disable the standalone build of ctdb.
> 
> Before we disable standalone build of ctdb, I would like to make sure that
> there is a way of building samba+ctdb rpms.  This might mean updating
> packaging/RHEL-CTDB and making sure it works.  The main reason for building
> RPMs is to be able to build samba/ctdb clusters for automated testing.  We
> have set up a nightly autobuild which builds ctdb rpms for various
> branches, creates virtual samba clusters and runs ctdb cluster tests.
> Currently autobuild does not run ctdb clustered tests and I don't want to
> lose the ability to do run clustered tests.

Providing example packaging is a good point, thanks!

> > This will make it also much easier to continue the way some
> > of us envision namely to integrate ctdb's clustering
> > more and more into samba, maybe splitting various
> > components out of ctdb, and removing the strict distinction
> > between ctdb and samba in the long run...
> >
> 
> I am currently not aware of any consumers of ctdb, other than samba.  If we
> really want to support ctdb as a clustering extension to tdb, so other
> applications can make use of it, then in the long run we need a proper
> (thread-safe?) ctdb library.  It would also indicate that we need to
> maintain the ability to run ctdb daemon(s) independently.

Of course I didn't mean to make it more difficult for other
potential consumers than samba. I was more referring to items
similar to the ones you mentioned above for "splitting ctdb
functionality into separate deamons". But whether all of these
daemons will be called ctdb-FOOd or samba-BARd or differntly
should be irrelevant for an external consumer, because these
are components of the samba distribution now anyways.


Question: Should we port the build changes to 4.2?
Since this is the logical consequence of shipping CTDB with
Samba, this seems reasonable.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141029/822e99fc/attachment.pgp>