How to move storage OEMs to Samba 4.0 ?

[simo]

On Wed, 2012-06-06 at 17:30 +1000, Andrew Bartlett wrote: 
> 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)

This changes with systemd.
Upstream is *strongly* recommended to provide scripts and distributions
are strongly recommended not to do their own.

So we should support the recommended scripts for systemd based
distributions.

> > 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. 

I tend to agree that it really depends on how and what we add.
But I am ok if the new features do not change behavior or break existing
systems.

> 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.  

I think we cna strike a compromise for minor features that have
absolutely no impact on existing functionality.

> > > 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?'. 

I agree on this one, no more 3.x releases once we decide 4.0 is good to
go.

> 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. 

OTOH it would make porting patches between 4.0 and 3.7 more complex, I
am not sure you are getting any net positive with this kind of trade.

> 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.  

The situation is different though, the architectural changes to the file
server were dramatic back then. Right now the architectural difference
in the file server between master and 3.6 are not so big, which makes it
tempting to try to backport stuff.
We should probably resist the temptation.

I think we can make OEMs life better if we provide a --file-server-only
build that will have the same dependencies and footprint of the current
file server. (well except for python, but that's fine)

I think that would go to great lengths to make it easier for OEMs to
adopt 4.0 for their file server needs.

Simo.

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