ABI stability of internal DBs

[Stefan (metze) Metzmacher]

Am 07.07.2010 06:24, schrieb Andrew Bartlett:
> On Tue, 2010-07-06 at 23:44 -0400, simo wrote:
>> On Tue, 2010-07-06 at 18:28 -0700, Jeremy Allison wrote:
>>> On Mon, Jul 05, 2010 at 09:50:38AM -0400, simo wrote:
>>>>
>>>> As far as I know we haven't decided about such a policy, but now that
>>>> you better described the issue, I wonder if we should discuss if such a
>>>> policy makes sense and if we should try to adopt one.
>>>
>>> Not for this kind of case IMHO.
>>
>> I tend to agree.
>>
>>>> But before even thinking of a database format compatibility rule we need
>>>> to understand if we can achieve this goal of allowing rolling upgrades
>>>> between one major version and the next. If we can't for other reasons
>>>> that go beyond the mere database format, then it doesn't make sense to
>>>> try to keep the db formats stable either.
>>>
>>> I don't think allowing such rolling updates is possible, and
>>> still allow us to add the features needed to keep Samba (non-clustered)
>>> moving forward in a timely fashion.
>>
>> Again, I said major but I meant Y version in the X.Y.Z scheme we have.
>> I guess we can keep guarantees that if I upgrade from 3.5.z to 3.5.z+n
>> it will not break things ?
> 
> If we do propose such a requirement, then we need something like the ABI
> checker to enforce it, or else such rules will be forgotten, and our
> promises will mean nothing.  
> 
> But even if we keep the structures the same size, we could change the
> behaviour based on those structures.  All of our testing is done with
> only the exact same version, and certainly not the cross-product of all
> the release versions, so I would argue any cross-version compatibility
> is completely untested. 
> 
> Should we be making such untested promises to exactly the users who need
> a highly reliable Samba?  If so, how can we provide (other than of
> course the due care and attention when making changes in the release
> stream) meaningful assurances here?

I'm against such a promise, if we need to provide a stable ABI, we
should do it
like we've done with libwbclient, where we introduced a stable API on
top of our internals.
With this we're still able to change the internals the pipe protocol,
but external users can rely on the stable libwbclient API/ABI.

I think this would be a much better way to provide access to the file
server locking state,
to the NFS-Server or other unix applications.

The cluster case is something different, there we just need upgrade pathes,
like we have already for passdb.tdb changes. This would basicly mean
we need to support 2 versions of a db formats, the current one and the
one before.
And we need an option to disable upgrades.

So you can add new nodes to a cluster and turn the upgrade on once you've
upgraded all nodes to the new software.

We may need a capability struct which contains the supported db formats
and features
the whole "system" supports and decide if we can upgrade to the latest
db format and features.
In the non clustered case it's simple, the "system" would support the
latest features.
In the clustered case it would be the union of all nodes.

This is a bit similar to AD, where all DCs have to support a specific
functional level,
before you can raise it for the whole domain or forest.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100707/5c6b94c9/attachment.pgp>