[SCM] Samba Shared Repository - branch master updated

[Volker Lendecke]

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.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100705/e507de77/attachment.pgp>