[RFC] Strategies for CTDB integration into Samba

[Michael Adam]

Hi,

Triggered by another mail thread, would like to officially
start the discussion or clarification, where we are heading
with the integrated CTDB.


What we have already done:
==========================

- CTDB code was intergrated into Samba code, because
  it is not (yet?) a project of its own.
  For instance, parts of the client implementation are
  in the samba code.

- CTDB's build system has been converted to waf, and
  some of the duplicated libraries have been removed.

- As of recently, the top level samba build has been
  extended to also build ctdb.

- CTDB has no version number of its own any more but
  will be released along with Samba as a component
  in the future, starting with 4.2.


What is going on:
================

- Amitay has just (re)proposed patches that remove
  the ability to build against older ctdb versions
  and maybe with the intention to disable the ability
  to build against external ctdb versions at all.
  (I think not quite achieved.)

- autobuild needs to be adapted.  Will post a patch.

- Selftest needs to be augmented to run the samba-ctdb stack.
  ==> I need to revive, finish and propose my
  clustered-samba selftest branches.


The question is now: Where do we want to go?
============================================

If we logcically pursue this path, I think the next steps
would be:

- to really disable the possibility to build
  against an external ctdb.

- maybe to make sure that samba is always build with ctdb.

- to disable the standalone build of ctdb.

This will make things a lot easier for our development
and make it much more clear, also to the distributors
and other consumers that ctdb is now considered a component
of samba that is only shipped and released as such.

We may need to guide the distributors and other consumers
how to make the change.

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...


Any comments or strong objections?
Otherwise, I think we should go that way.


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/20141024/8951fdef/attachment.pgp>