How to move storage OEMs to Samba 4.0 ?

[Andrew Bartlett]

On Wed, 2012-06-06 at 08:52 +0200, Andreas Schneider wrote:
> On Tuesday 05 June 2012 16:16:53 Jeremy Allison wrote:
> > Hi all,
> 
> Hi Jeremy,
> 
> > So the full Samba 4.0 release will occur soon (*), and we need
> > to think about how to work with OEMs on this. Currently most
> > Samba OEMs are file serving only, and are on a combination
> > of 3.5.x and 3.6.x.
> 
> the same applies more or less for enterprise distributions. We still have to 
> ship 3.6.x untils 4.0 is out and we will have to support it for quite some 
> time.
> 
> The next thing is we need to discuss how we support the file server part in 
> 4.0.
> 
> Do we support to run smbd standalone?

Yes.  Unless you want an AD DC then nothing changes.  Same binaries,
same options, same behaviour (well, with SMB3 goodness thrown in :-)

> Do we support and upgrade path from smbd setup to full DC provision?

Yes.  samba-tool domain samba3upgrade

> What scripts and init scripts do we provide for this?

I guess we need a way to start 'samba' for users who are running the AD
DC.  Mostly this is a packaging issue (from memory, we don't supply many
init scripts, and most packages don't use the ones we supply anyway)

> I've started with systemd support, see packaging/systemd
> 
> > 1). Once 4.0.x ships, relax the rules on functionality
> > additions to 3.6.x so that we can add *some* limited new
> > functionality like bugid 8926, or the pthread aio code,
> > or the new VFS module someone wants to submit. *Maybe*
> > VFS changes (not sure about that..).
> > 
> > We will of course commit to doing this only for a year or
> > so. Requirements for new SMB3.0 functionality will attract
> > OEMs to 4.0 eventually. This is *close* to what we're
> > doing now, but it losens up the restrictions we currently
> > have on adding new code.
> 
> That's the way to go, as also enterprise distribution will have to support it 
> for quite some time.

Do we really want to break our own rules about new features? 

Particularly if enterprise distributions are relying on it as being
'fixes only' (so that they actually upgrade, rather than only apply
patches), changing the rules here worries me. 

Debian finally managed to release new versions of Samba (rather than
just patches) in stable because we promised to follow a strict
'fixes-only' rule.  

We also struck such a hard line because we had trouble stopping the
continual backport of features to our 'stable' releases, which in turn
meant that they were less stable, and there was no reason to concentrate
on and release the next real release. 

I can't find exactly where we wrote it down, but this is what we have in
the 3.x release planning:
https://wiki.samba.org/index.php/Samba3_Release_Planning

Now, it's our project and we are free to change our own rules, but it
feels like a can of worms.  

> > 2). Once 4.0.x ships, fork off a 3.7.0 tree from the current
> > 3.6.x tree and add the limited new functionality there. As
> > this is post 4.0.x ship then we still recommend 4.0.x for
> > all users, but we have the ability to add *limited* new
> > functionality to a "trusted" release that is very close to
> > what storage OEMs currently depend on.
> 
> BIG FAT VETO. I think this will send a wrong message. Doing this is like 
> saying that 4.0 is not ready and mature enough.

Additionally, it brings a long support burden, as that stream will be
expected to be supported for quite some time - far beyond what even
extended support on 3.6 would look like, because it is starting as a
'new' release.  Of course, we can redefine our support rules if we want,
but we would need to be quite clear about the role of this special case.

I do fear it will cause user confusion such as what you suggest and
questions of 'where is the real file server?'. 

The only way I can see this helping us is if it allows us to trim a
different part of our support burden.  Everybody knows that stopping
having two complete build systems is my hobby-horse at the moment - if
this was a way to then remove that burden from 4.0, we might at least
have some payback.  At least most of the fixes for 3.6 and 3.7 would be
combined. 

But more seriously, this really does feel like the situation with Samba
2.2 just before 3.0 was released.  There was great pressure from vendors
to backport 'just libads' to the 'stable' Samba 2.2, and many other
features that were to be the new thing with Samba 3.0 were pushed into
the later 2.2 releases.  

Either approach for re-opening development creates trouble - the reason
that our OEMs want to use the old versions is because they are well
known and not changing.  They just want to have their cake and eat it
too - blessed, unchanging stable versions, but with just the few extra
features they want.  My view is that is best done in-house or with some
optional patches, and that otherwise the wait for Samba 4.0 to gain a
stable reputation will be good for them, and good for us. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org