[SAMBA4] we should create just one test environment

[Andrew Bartlett]

On Mon, 2007-04-30 at 11:04 +0200, Jelmer Vernooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 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.  
> 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 uses
> the latter at the moment. That makes it a little bit more complex, but
> the alternative is a complex test environment.

I would prefer a more complex, but realistic test environment that is
static, for most configurations.  That way, I know where things are, and
can easily aim tests (including ad-hoc tests/debugging in 'make
testenv') at whatever parts I need.

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

Perhaps I'm just too simple of mind for this job.

> >>> 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...
> Well, I was thinking of the case where two DCs were in different domains
> 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.

If the cost is a few environment variables, that's a reasonable cost. 

> 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.

I want to see it scale at least to the reasonable cases we currently
have.  

> >>> 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.  
> At the moment, it is very easy to create a test network that contains a
> Samba4 DC and a Samba3 member server or a Samba3 DC and a Samba4 member
> 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 of
> 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.

I'm quite happy for tests to declare what environments they need, but
for the moment, I would really like all those environments to be
provided.  

I'm simple of mind, and I just don't like my test target moving in front
of me.

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/df81ca28/attachment.bin