[SCM] Samba Shared Repository - branch master updated

[simo]

On Tue, 2010-07-06 at 08:31 +1000, Andrew Bartlett wrote:
> On Mon, 2010-07-05 at 11:04 -0400, simo wrote:
> > 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.
> 
> Why only major versions?  Surely this kind of thing could just as easily
> crop up in minor versions too?

By major I mean Y versions.
And we are usually very careful about not breaking stable versions.

> > 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 ?
> 
> Perhaps the Samba version including GIT hash, plus an optional
> 'compatible with' string that would be hand-written to cover the cases
> where a minor change is deliberately and carefully added into the
> cluster (security fix etc)?

The Y version should be enough, we do not do dangerous changes in
stable releases, and our users rightfully expect things not to break
between minor versions of a stable release.

Simo.

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