samba - Dec 2016 - ntvfs file server and selftest background

On Mon, 05 Dec 2016 21:07:48 +1300
Andrew Bartlett <abartlet at samba.org> wrote:

> 
> It is a lot of work to change the situation, even more so without loss
> of important tests.  A number of tests, particularly for spoolss but
> also of the cifs proxy (which in turn tests kerberos delegation), use
> the ntvfs file server.
OK, but how can you be sure that something you are testing against
ntvfs actually works with s3fs ? 

Rowland

On Mon, 2016-12-05 at 08:12 +0000, Rowland Penny via samba
wrote:
> On Mon, 05 Dec 2016 21:07:48 +1300
> Andrew Bartlett <abartlet at samba.org> wrote:
> 
> 
> > 
> > 
> > It is a lot of work to change the situation, even more so without
> > loss
> > of important tests.  A number of tests, particularly for spoolss
> > but
> > also of the cifs proxy (which in turn tests kerberos delegation),
> > use
> > the ntvfs file server.
> 
> OK, but how can you be sure that something you are testing against
> ntvfs actually works with s3fs ? 
The spoolss tests are testing the (very odd) rpc call-back
functionality that requires the spoolss server to make a reverse call
to the client to deliver the notifications.  The ntvfs file server
helps provide one of the layers involved, to allow the smbtorture
process to listen as an smb server and then provide a specail RPC
interface.

As we don't otherwise implement the client side of this protocol, the
means used to implement it are not important, we are testing the server
against a instrumented mock implementation.

This isn't the only reason that part of the codebase is used, but I
hope I can clarify at least this one for you.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

On Mon, 05 Dec 2016 21:30:20 +1300
Andrew Bartlett <abartlet at samba.org> wrote:
> On Mon, 2016-12-05 at 08:12 +0000, Rowland Penny via samba wrote:
> > On Mon, 05 Dec 2016 21:07:48 +1300
> > Andrew Bartlett <abartlet at samba.org> wrote:
> > 
> > 
> > > 
> > > 
> > > It is a lot of work to change the situation, even more so without
> > > loss
> > > of important tests.  A number of tests, particularly for spoolss
> > > but
> > > also of the cifs proxy (which in turn tests kerberos delegation),
> > > use
> > > the ntvfs file server.
> > 
> > OK, but how can you be sure that something you are testing against
> > ntvfs actually works with s3fs ? 
> 
> The spoolss tests are testing the (very odd) rpc call-back
> functionality that requires the spoolss server to make a reverse call
> to the client to deliver the notifications.  The ntvfs file server
> helps provide one of the layers involved, to allow the smbtorture
> process to listen as an smb server and then provide a specail RPC
> interface.
> 
> As we don't otherwise implement the client side of this protocol, the
> means used to implement it are not important, we are testing the
> server against a instrumented mock implementation.
> 
> This isn't the only reason that part of the codebase is used, but I
> hope I can clarify at least this one for you.
> 
> Thanks,
> 
> Andrew Bartlett
> 
Sorry, but no, it doesn't clarify anything. What you didn't say is
whether anything will actually make the rpc call in the real world. If
nothing ever will, then there is no point in testing it. What I am
trying to get at, using ntvfs in testing, then moving to s3fs in
production, is a like test running an engine fitted with a
carburettor, then fitting fuel injection in production without further
testing, just how are you supposed to be sure it will work correctly ?

I thought the whole idea behind testing, is to actually test what will
be used, or am I wrong ?

Rowland