ABI stability of internal DBs

simo idra at samba.org
Wed Jul 7 06:08:55 MDT 2010


On Wed, 2010-07-07 at 12:46 +0200, Stefan (metze) Metzmacher wrote:
> Hi Volker,
> 
> > On Wed, Jul 07, 2010 at 11:20:22AM +0200, Stefan (metze) Metzmacher wrote:
> >>> Ok, so you are proposing that for all our internal databases
> >>> like locking.tdb we create stable APIs like libwbclient,
> >>> along with the messaging protocols, which need to be
> >>> encapsulated similarly?
> >>
> >> No, only for things which need to be accessed by other applications.
> >>
> >> For internal things we just need to support for 2 versions
> >> of a protocol or db format, how we do that doesn't
> >> matter...
> > 
> > That's exactly the testing nightmare that I tried to lay out
> > earlier. We can do that, but this will slow us down
> > tremendously. If we make that promise, we will potentially
> > have to support n different versions. Vendor A will require
> > the upgrade from 3.3.10 to 3.5.4, Vendor B will require the
> > upgrade from 3.4.7 to 3.6.1. Vendor C will step in with yet
> > another combination.
> 
> I thought this would be limited like this:
> All 3.B.x versions will use the same formats and features.
> And they only need to support upgrades from 3.A.x versions.
> 
> If someone needs to upgrade from 3.3.10 to 3.5.4, it's needed
> to first upgrade to 3.4.8, before upgrading to 3.5.4.

FWIW this goes way beyond what I proposed. I proposed only that 3.5.1 be
compatible , in the cluster case, with 3.5.X.

I think it is ok to ask the cluter to be shut down and restarted if you
go 3.6.x

> > If that is our decision from now on, we will need MUCH
> > better review of all changes. Mandatory tests for the
> > upgrade procedures and tests with running clusters with the
> > promised upgrade versions will need to be designed.
> > 
> > I wonder who will provide the resources for this testing
> > infrastructure. RedHat? IBM? SuSE? Other vendors with
> > clustered Samba?
> 
> I'm not proposing that we give such a promise. I'd actually like to
> avoid it.
> 
> I just explained a possible technical solution, which would still be a
> hell lot of work.
> And I guess we're not able to handle it with our current resources.

So we are not able to promise stability of DBs within the same stable
release series ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>



More information about the samba-technical mailing list