-----BEGIN PGP SIGNED MESSAGE-----
Andrew Bartlett wrote:
> On Mon, 2007-04-30 at 11:04 +0200, Jelmer Vernooij wrote:
>> 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
>>>>>> 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
>>>> 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.
What is more realistic about such a test environment? It's just more
complex than the current test environments and can make debugging harder
as there are more factors involved than can cause problems.
Things will still be where they are. I just don't see why you would be
interested in $RANDOM-DOMAIN-MEMBER when you're running a couple of SAMR
tests against a DC.
>>>>> 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.
My point is, that is also complexity. Not much, but the same thing could
be said for multiple test environments.
> 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
Like you use 'make testenv', I use "make test TESTS=<NAME>" all the
time. It's very annoying if I have to wait not 10 but 20 or even 30
seconds for provisioning to finish.
I don't mind 'make testenv' setting up more than one environment so you
can do more ad-hoc testing/debugging. Or perhaps having 'make testenv'
set up all environments, while 'make testenv-dc' or 'make
testenv-member' set up just one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----