Converting SMB1 tests to SMB2

[Noel Power]

Just FYI

I opened https://gitlab.com/samba-team/samba/merge_requests/902

This branch is a return to the plan of just using some independent CI
jobs to run the SMB1 tests (and tests failing in environments where SMB1
can't be negotiated). These new jobs use simple 'shallow' copies of the
existing environments.

I returned to this approach due to the ever increasing amount of changes
(and I admit failure) trying to create proper independent test
environments (as described below)

Maybe we can try with the approach outlined in the merge request and
continue the discussion there. The sooner we have something in place
upstream the sooner we can start chipping away at the tests :-)

Noel

On 08/11/2019 14:03, Noel Power via samba-technical wrote:
> 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
>
>