[SAMBA4] we should create just one test environment

Andrew Bartlett abartlet at samba.org
Mon Apr 30 07:43:23 GMT 2007

On Mon, 2007-04-30 at 10:22 +0200, Jelmer Vernooij wrote:
> Hash: SHA1
> Andrew Bartlett wrote:
> > On Mon, 2007-04-30 at 09:03 +0200, Jelmer Vernooij wrote:
> >> Andrew Bartlett wrote:
> >> Nothing prevents test environments for guaranteeing both a dc and two
> >> members will be up, for example. 
> > I'm asking that that be the default, that we create exactly one test
> > environment for the vast majority of the tests we run.  
> I don't see what that would add. Why should we set up a domain member if
> we just one need a dc to run against?
> If we'd have one such "sane default", then there is no point in having
> multiple environments at all.

Indeed, and aside from the value in allowing a 'none' environment, and
possibly the Samba3 stuff, I'm yet to be convinced of the need for
multiple environments. 

> >> Also, the current code makes it very easy to add support for other
> >> targets (Samba3, for example) that don't support all test environments
> >> (yet).
> >>
> >> Perhaps you would simply like to make sure that all test environments
> >> are set up in 'make testenv' ? 
> > No, then the tests will constantly differ from the environment in which
> > they are normally run, even worse than the current situation.
> In that case, why not add an ENV= variable so you can run "make testenv
> ENV=member" ? Or perhaps we can simply add "make testenv-dc" and "make
> 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, and
it isn't any more.  

> > I'm afraid that the selftest setup is becoming too complex to reproduce
> > - I want to be able to easily reproduce any failure in 'make
> > testenv' (which you will recall is my primary work tool), without first
> > 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 the
> dcs or domain member.

Well, the first point is that DC1 and DC2 *should* be sharing the same
username and passwords.  The member server will have additional local
users (to verify the local SAM), but the whole point of a member server
is to use the same passwords...

> 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 expensive.
I expect to do some work to allow two DCs to share a ldb (for one modal
of replication), and for the DRSUAPI replicated case, we just need to
setup a skeleton. 

> > It doesn't seem too much of a price to always have a simple network
> > running, that contains the DC (or 2), and member servers.  Then we can
> > 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 fact
> 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.  

I don't mind having other environments, but I would much rather one
'test network' than the current fragmented setup. 

Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20070430/9112e8df/attachment.bin

More information about the samba-technical mailing list