CTDB in master?

[Michael Adam]

On 2013-10-31 at 10:52 +1100, Amitay Isaacs wrote:
> On Thu, Oct 17, 2013 at 6:48 PM, Michael Adam <obnox at samba.org> wrote:
> >
> > What we really need to agree on and discuss (and especially
> > Amitay's voice is needed here) is how we will do CTDB releases
> > in the future:
> >
> > - Will we just release ctdb as a component of samba
> >   starting with 4.2 and drop the independent version numbering?
> >
> > - Or will we do it as with talloc, tdb and friends, i.e.
> >   independent releases.
> >
> 
> Currently ctdb does not behave like other libraries (talloc, tdb, ...).
> There is no libctdb implementation which samba can build against.  Samba
> directly includes the private ctdb headers and re-implements most of the
> protocol.

Well, I'd say the implementation of the "ctdb protocol" is spread
across ctdb and samba code. Many of he pices that samba implements
are not implemented in the ctdb code, right?

And I was not referring to the "library nature" of tdb and
friends but rahter to the fact that ctdb has up to now had
a separate version numbering (however creative).

But it is fair enough to put ctdb versioning under the samba
versioning for now. But this means that we will also have to
freeze and stabilize the ctdb releases in sync with the
samba releases, something that has not been done on the past.

> Till we have a libctdb implementation that is complete, and Samba
> code in  ctdbd_conn/dbwrap_ctdb is using libctdb, there is no point in
> doing separate CTDB releases.  That just creates confusion -- which CTDB
> version to be used with which Samba version.

I agree: There will be a _default_ version of ctdb to use with Samba.
But I think we will still need to be able to run (/build) Samba
with ctdb version other than the bundeled one, especially for
distributors and vendors of storage products this might be
important.

> > One could argue that the reason for putting CTDB into the samba
> > repo, namely the fact that ctdb is actually not ready to be a
> > separate project yet, implies that ctdb versioning and releases
> > should be aligned with samba. I am not quite certain yet.
> >
> 
> I agree. At least till we have a working libctdb, we should not do separate
> releases.

OK. This means that you hand release management of CTDB
(for new releases) over to Karolin once CTDB is merged into
Samba master, right?

> > Anyways we need to tell how to treat stabilizing ctdb
> > versions and make sure the file server part can still be
> > run with ctdb version other than the shipped one.
> >
> 
> In future, we would be able to separate CTDB as a standalone project with
> it's own versioning if we need faster release cycles than Samba.  By then
> we should be able to mix versions of Samba/CTDB as CTDB features will be
> decided at runtime and we shouldn't need to restrict features at
> configure/compile time.

I need to think about it.
As said above I was assuming that we need to keep the ability
to build Samba against older versions of ctdb for now.

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