To release Samba 4.0 'as is'

[Michael Adam]

Hi Andrew,

Andrew Bartlett wrote:
> On Wed, 2011-12-07 at 10:06 +0100, Michael Adam wrote:
> >
> > 1. What version should contain which components?
> > 
> >   As I stated in a previous mail, this is my view:
> > 
> >   * As soon as a reasonable feature set of the AD server is
> >     releasable in a fashion sufficiently integrated with the
> >     s3 smbd file server, we should do the 4.0 release.
> > 
> >   * Until that stage is reached, we should continue doing
> >     3.X fileserver releases if new features in s3 are worth
> >     releasing.
> > 
> >   Is that something we can agree on?
> >   This is imho the first and most basic thing we need to agree
> >   (or disagree) on.
> 
> I do not think we have agreement on that, particularly as we already
> agreed that our next release would be Samba 4.0.

No, to my memory, we have agreed that we would _like_ the next
release to be 4.0 (i.e. the first release containing the s4 ad
server) nothing more!

That is we would well be releasing more 3.X releases, i.e.
releases without the s4 ad part, if finishing 4.0 takes too long
and s3 features worth releasing are ready before that.

> If we feel we cannot call our next release Samba 4.0 for some
> reason, then we should allow a release of the AD components in
> the interim as Samba4AD or some other name.

That would be exactlty working against everything we have tried
to achieve in the last 1-2 years, namely forking instead of going
towards the combined release.

If you ask me (and I thought we had agreed on it),
this is my very high level summary:

1. The first release containing the s4 ad part should be a
   full release in direct succession of the 3.X releases.

2. This first release should be called 4.0.0

3. Since it should be a full combined release, it needs
   the "integration" part to be finished to some reasonable
   extent.

4. It would be nice if the next release would be 4.0.

5. We will continue releasing 3.X feature releases though,
   as long as release-worthy s3 features are finished before
   the 4.0 goal is reachable.
   (We need not adhere to any fixed minimum delay between
    a 3.X and the 4.0 though, as far as I am concerned.)

> > 2. Next thing to decide is what components to use together.
> > in the AD-server mode.
> > 
> > * I think I am not misinterpreting our previous discussions
> >   when I state that we have agreed to have the s3 smbd file
> >   server as the default file server. We can keep the s4
> >   file server around and provide an option for enabling it
> >   for testing/debugging and existing production setups for
> >   some time at least.
> 
> If our file server is moving in the direction that metze indicated with
> the NTFSA layer, it seems prudent to keep our working modal of such a
> pattern (ntvfs).  In any case, the overhead to keep it is quite minimal,
> and as a developer, I can assure you that the single process modal it
> enables makes it much easier to debug issues in the AD server. 

As stated above, it seems reasonable (to me) to keep the s4 file
server around for now, based on Tridge's arguments (better
ad-debuggability in the lab and support for early production
users). The ultimate goal should be to have one file server only
at some point in the future. And the move in the s3 file server
towards a layering more similar to the ntvfs layer of s4 (which
we are in fact currently planning and starting to work on), is to
my understanding rather an argument for being able to reach the
goal of a common (s3-smbd based) single file server rather sooner
than later. Not and argument for keeping the s4 file server
longer. But I think that this point is irrelevant at this phase
in the discussion. Time will tell how fast we can reach having
just one file server after 4.0 has been released.

> > 3. Next is the question of "integration", i.e. how should the
> >    main samba daeomon and the chosen s3 components (especially
> >    smbd) interoperate? As separate daemons (e.g. smbd spawned
> >    by "samba") via the rpc channels and so on (basically the
> >    franky approach) and via the pdb_samba4 or pdb_ads modules,
> >    or via direct function calls, the smbd part loaded as shared
> >    object (basically the libs3compat approach).
> > 
> >    My impression here is that the franky style approach will
> >    probably be the way to a releasable state (it is in fact
> >    already used in the univention setup), but this might as well
> >    be due to lack of knowledge about the stage of the s3compat
> >    efforts.
> 
> It would be well worth looking carefully at how the plugin_s4_dc
> environment is set up in the test system.  The named pipes are
> forwarded, and the plugins provide consistent access to the
> authentication and authorization layers.  Tridges s3fs-wip branch is
> also worth a look.

I hope I'll finde some time to look into these more thoroughly, soon.

> The lesson learned from a long time working on the integration effort is
> that how the smbd code is started is the smallest detail of the work
> required here: the hard work is the behaviour once a connection is made.

Sure, but the mode of launching lays the foundation for the real
problems: how do the various components interoprerate, via
external interfaces (rpc, etc) that already exist or internally
via function calls calling into a smbd loaded as shared object.

> The big tasks like reconciling (if not merging) loadparm, and smaller
> but still important details such as handling GSSAPI secured connections
> to s3 rpc pipes are all the same regardless of the 'grand scheme' of how
> the smbd code is launched.

Well, maybe. But maybe it is less important to solve them _now_
if the external communication paths are used. This is what the
Franky approach tried to show: That with using separate deamons
with external communication we could release earlier and hence
give us more time to do the merging work more slowly. Of course,
the ultimate goal should be the completely merged code. As I said
above, I hope to find some more time to look into the ntegration
topice soon.

Cheers - Michael

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