Fwd: Re: [SAMBA4] we should create just one test environment

Sasja Solomons sasja at rsp.co.za
Mon Apr 30 11:13:13 GMT 2007

How do I unsubscribe from this newsletter forum?


From: Jelmer Vernooij <jelmer at samba.org>
To:Andrew Bartlett <abartlet at samba.org>
Date: 2007/04/30 10:04
Subject: Re: [SAMBA4] we should create just one test environment
CC:<samba-technical at samba.org>
Hash: SHA1

Andrew Bartlett wrote:
> On Mon, 2007-04-30 at 10:22 +0200, Jelmer Vernooij wrote:
>> Andrew Bartlett wrote:
>>>> Also, the current code makes it very easy to add support for
>>>> targets (Samba3, for example) that don't support all test
>>>> (yet).
>>>> Perhaps you would simply like to make sure that all test
>>>> are set up in 'make testenv' ? 
>>> No, then the tests will constantly differ from the environment in
>>> they are normally run, even worse than the current situation.
>> In that case, why not add an ENV= variable so you can run "make
>> ENV=member" ? Or perhaps we can simply add "make testenv-dc" and
>> testenv-member"?
>> We can print out the environment name for failed tests, if that
would help.
> I just think it's getting too complex.  It used to be very simple,
> it isn't any more.  
The only added complexity would be that there isn't just 'testenv' but
'testenv-dc' and 'testenv-member', and there is just one test that
the latter at the moment. That makes it a little bit more complex, but
the alternative is a complex test environment.

I also think the concept that a test has to run against a particular
kind of server isn't particularly hard to grasp.

>>> I'm afraid that the selftest setup is becoming too complex to
>>> - I want to be able to easily reproduce any failure in 'make
>>> testenv' (which you will recall is my primary work tool), without
>>> wondering 'oh, what environment did it declare, what environment
did it
>>> get, and what environment do I have now'.
>> That will make other things more complex. For example, we'd need to
>> change the environment variables to be $DC1_IP, $DC1_USERNAME,
>> $DC2_PASSWORD, etc because the tests can be run against either of
>> dcs or domain member.
> Well, the first point is that DC1 and DC2 *should* be sharing the
> username and passwords.  The member server will have additional
> users (to verify the local SAM), but the whole point of a member
> is to use the same passwords...
Well, I was thinking of the case where two DCs were in different
but had a trust between them. So, in the case of two dc's in the same
domain, you would have a $DC_USERNAME and $DC_PASSWORD but also
passwords and ips for various member servers.

>> It also makes things like "make test TESTS=SAMR" slower as the
>> provisioning is two or three times as slow.
> Provisioning for an additional DC should not be particularly
> I expect to do some work to allow two DCs to share a ldb (for one
> of replication), and for the DRSUAPI replicated case, we just need
> setup a skeleton. 
Provisioning by itself is relatively slow. If I run "make test
TESTS=RPC-SAMR" a lot of times in a row when I'm trying to fix
it does matter that provisioning takes twice as long.

I also imagine we'll have a different environment that provides a
NT4-style DC. Eventually we may end up with a dozen or more
servers and that will cost us. It may work for just one dc and member
but won't scale.

>>> It doesn't seem too much of a price to always have a simple
>>> running, that contains the DC (or 2), and member servers.  Then we
>>> be very consistent in how our tests run, and are debugged. 
>> It's not just the time it takes to set up the environment, also the
>> that it makes it harder to support other targets (because of the
>> complexity of the environment they need to support) and the
inability to
>> mix environments. 
> I really don't understand what you mean here.  
At the moment, it is very easy to create a test network that contains
Samba4 DC and a Samba3 member server or a Samba3 DC and a Samba4
server, etc.

If we'd need to set up the same environment for a different target
(Windos or Samba 3), we'll have to replicate the exact same situation
including all the various different dcs/members before we can run any
the tests or we need to keep a list of targets against which a
particular test can run. In the current situation, we can simply skip
all tests that require an environment that is not available.


Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org (
http://enigmail.mozdev.org/ )


More information about the samba-technical mailing list