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
On Mon, 2016-12-05 at 08:47 +0000, Rowland Penny via samba wrote:> 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 ?Don't worry, the smbd file server is also extensively tested. 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 Tue, 06 Dec 2016 04:31:34 +1300 Andrew Bartlett <abartlet at samba.org> wrote:> On Mon, 2016-12-05 at 08:47 +0000, Rowland Penny via samba wrote: > > 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 ? > > Don't worry, the smbd file server is also extensively tested. > > Andrew Bartlett >That is not the point, if you are testing 'something' against ntvfs & s3fs, then surely the ntvfs test is no longer required. If you are testing 'something' against ntvfs but not testing it against s3fs, how do you know it works with s3fs ? Surely testing using a component that isn't used in production isn't a good idea, wouldn't it make more sense to alter all the tests to use s3fs instead of ntvfs ? Rowland