[SCM] Samba Shared Repository - branch master updated

simo idra at samba.org
Tue Jul 6 21:44:06 MDT 2010


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 ?

I am fine if 3.y.z -> 3.y+n.z doesn't work, without a complete shut down
and upgrade of all cluster members.

> > 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 ?
> 
> An error message sounds good :-).

Only if you mean the error message will be fired by the new member, not
if adding a new member disrupt existing ones.

Simo.

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



More information about the samba-technical mailing list