Converting SMB1 tests to SMB2

[Noel Power]

Hi All,

On 06/11/2019 17:44, Andrew Bartlett via samba-technical wrote:
> On Fri, 2019-11-01 at 18:31 +0000, Noel Power via samba-technical
> wrote:
>> Hi All
>>
>> Just thought I summarize what we (myself & Ralph) discussed, for my own
>> benefit and the benefit of others.
> Thanks for writing this out.  I see in the rest of the thread that you
> have made some progress,

well yes and no :-)

so, I did try and fix the ip uniqueness thing but...

unique ips made some difference however there were more things, more
changes needed

a) need to pass down a unique server name in order that the unique ip
can be created (there is a name -> interface_num hash)
b) but... we have alot of fake _smb1 envs and the number of interfaces
we have  breaks the current MAX_WRAPPED_INTERFACES limit, need to modify
this in third_party/socket_wrapper/socket_wrapper.c
c) missing certs for various tests which needed some new directories
(and content) setting up in various dirs under
selftest/manage-ca/CA-samba.example.com/DCs/
e) there is another problem, there is still interference between the
environments because an additional realm_to_ip_mappings where the realm
associated with the servername (and where the servername in turn is used
to get the ip address)
f) I then tried to use different realms with the smb1 environments who
should have entries in the table but this also was not enough, still
tests fail (I presume because lots of test data, database entries etc.
depend on the existing 'realms' used (this is speculation)

So  CI still doesn't pass, at this point I just got too disheartened,
been going around in circles, don't know enough about the test setup (or
samba ad) to figure out (at least easily). I get the impression this is
a piece of string I could pull for a long time :-) and the only thing
that will be unravelled is my sanity

The current errors with this approach can be seen here
https://gitlab.com/samba-team/devel/samba/pipelines/94064858

>  but wanted to say that if you get really stuck
> again then I can certainly be of assistance. 

thanks, appreciated!!, I wonder would you think or agree that rather
than go down the rathole above that reverting to my backup plan which
just added 2 new smb1 jobs is a far easier route, we don't need the
runaway changes to the '_smb1' environments as above. ip uniqueness for
example should not be an issue as we run those tests in isolation in
their own CI job/container, these jobs/environments will go away when
SMB1 disappears anyway. Hopefully using such 'shallow' copy versions of
the environments isn't an issue or a stumbling block ? [1]

But... there still remains the problem that in the last attempt a number
of tests were failing mysteriously in the new separate smb1 CI jobs. I
scratched my head on this, again I tried to reproduce the problems
locally, in docker and on sn-devel without success (everything passes
outside of CI). So, I returned to running just a single failing test on
CI (now with lots of DEBUG) and found for example that with the
samba3.unix.info2 test that immediately after creating a file with (0
bytes allocated) that STAT returns st_ex_blocks with a positive value.
Clearly this is something happening at the host os or filesystem level.
Comparing with passing tests in master the only difference is the
passing tests run on rackspace runners and with the failing case, the
tests run on shared runners. Changing the new smb1 jobs to run on
rackspace solves the problem

see https://gitlab.com/samba-team/devel/samba/pipelines/94604792

so...

1st can anyone enlighten me as to what is different with the rackspace
runners?
2nd can we agree that adding the 2 new jobs is the simplest and easiest
way forward, once upstream this will allow us to iteratively tackle the
SMB1 failing tests

thanks,

Noel


[1] One potential problem is that the default 'make test' from source
will fail because of the mix or xyz & xyz_smb1 environments. However
  + personally I doubt that 'make test' reliably will succeed anyway
these days, we certainly don't test a full make test anywhere anymore,
imo the only reliable way to run tests is via gitlab CI (or autobuild)
  + with the python3 port there were jobs that were completely
unreliable until they were separated into python/python-3 jobs. There
were certainly a number of tests that couldn't be run multiple time in
the same env (due to destructive nature of the tests) so I think we have
already done this before