[SCM] Samba Shared Repository - branch master updated

[simo]

On Mon, 2010-07-05 at 16:03 +0200, Volker Lendecke 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.
> > 
> > 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.
> 
> Look at for example at struct share_mode_entry which is in
> locking.tdb. Jeremy has put in a change to make op_mid 64
> bit wide, which also breaks rolling code upgrades. That's
> why I thought it would be okay to break it with
> connections.tdb as well, nobody has complained about
> Jeremy's checkin. It will be a tremendous effort to keep
> that compatible, we definitely need mapping layers between
> both database formats. I don't even want to start thinking
> about what it would mean to add things like durable file
> handles or new oplock modes that require new messages sent
> back and forth between the smbds. We should probably just
> roll back the changes Jeremy has made to accomodate SMB2,
> this is just not doable in the current time frame with the
> number of people we have.
> 
> If projects like GFS, Lustre or all the other cluster file
> systems are the precedence to always provide seamless
> upgrades while the cluster is running, probably Samba which
> is part of that world now needs to keep up. This will slow
> us down horrendously and is a complete testing nightmare
> though.
> 
> > However assuming we do not keep DB formats stable, what will happen if
> > someone tries to join a new samba version to a CTDB cluster ?
> > Will it warn something in the logs and shutdown itself ? Or will it try
> > to write database entries and compromise the functionality of all other
> > nodes ? Or is there some other mechanism that will prevent harm in any
> > way ?
> 
> Nothing right now will warn you.

Ok, from what you say above trying top keep compatibility between major
versions is going to be a nightmare both in terms of required discipline
and in terms of pure testing and checking all is fine.

Then, shouldn't we add a version number in some shared file or database,
or startup message so that if you try to add an incompatible version to
the cluster it won't even start and give out a clear error ?

My only concern here is to avoid having customers shoot their own foot
unknowingly.

Makes sense ?

Simo.

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