How to move storage OEMs to Samba 4.0 ?

[Jeremy Allison]

Hi all,

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.

I'm hoping that with the full release of Samba 4.0, we
might be lucky and get a whole host of very welcome new OEMs
selling products around AD Domain servers. I'm not worried
about these OEMs :-). These people are well aware of what
we do and don't do (or they won't have a very good product :-)
and hopefully are already working closely with members of
the Team.

The file serving OEMs I work with are more conservative.
Normally they stay a release or about 1 year behind our
current latest code, for stability reasons. It's hard to blame
them, storage is an inherently conservative business, and
they have to wait until the consensus is that a release is
good enough to run multi-petabytes (or even exabytes) of
storage on.

So, realistically, most Samba storage vendors are going
to stick with 3.6.x for the next year or so. The question
is, how to provide them with functional updates on that
code until they feel comfortable enough to go with the
version of 4.0.x that is current ?

I'm not talking about regular bugfixes here, but bugs like:

https://bugzilla.samba.org/show_bug.cgi?id=8926

"Please use vfs_shadow_copy2 from master".

Currently this is closed out, due to it being a functionality
addition. I think we need to find a way to handle this
without expecting all storage vendors to move immediately
to the 4.0.x fileserver.

My feeling is we can do this with some version of carrot
and stick. The carrot is we keep maintaining the 3.6.x
codebase once 4.0.x is released - so they know that their
current "stable" product remains supported and fixes come
in a timely fashion. This is what we ordinarily commit to
do for and are currently doing for 3.5.x.

The stick is that the SMB3.0 functionality which requires
major structural changes to the core fileserver code is
*only* done in 4.0.x and above.

However this leaves a grey area of functionality additions
that are really useful (e.g. the aio_pthread code which
I snuck into 3.6.x) but not large rewrites. So I can see two
options here (there are more, but these are the ones I think
are workable) :

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.

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.

What do people think ? My personal preference is for option
(1), but I'm open to other ideas. The problem we have to
solve is that OEMs do need some of these code changes, but
will not immediately move to 4.0.x for a year or so. So
whatever response has to at least address this problem - merely
saying "let them use 4.0.x" isn't going to solve it, because
trust me they won't.

Jeremy.

(*) for some small value of soon :-).