[SCM] Samba Shared Repository - branch master updated

[Andrew Bartlett]

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?

> 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)?

(Samba4's code has recently been extended to ensure that this version
string is always updated to reflect the current GIT hash). 

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

That seems a reasonable concern, which I think we should address in
terms of 'fail to start' rather than 'prevent changes'. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100706/b123790f/attachment.pgp>