So, this is the new rule to end each test. Got it.
{{{
220 topology.standalone.stop(timeout=10)
220 topology.standalone.delete()
}}}
And thank you for cleaning up the code! I noticed you removed one ';' at the end of line... :p

Replying to [comment:2 nhosoi]:

So, this is the new rule to end each test. Got it.

Yeah, so as long as you use an existing test as a template for a new one, it should be covered :-)

{{{
220 topology.standalone.stop(timeout=10)
220 topology.standalone.delete()
}}}
And thank you for cleaning up the code! I noticed you removed one ';' at the end of line... :p

Yeah there were a few ";" that needed to be cleaned up :-)

All the tests pass when run with "py.test"

{{{
$ PREFIX=/home/mreynolds/install py.test -v
=============================================== test session starts =========
platform linux2 -- Python 2.7.5 -- pytest-2.4.2 -- /usr/bin/python
collected 168 items

ticket47313_test.py:124: test_ticket47313_run PASSED
ticket47313_test.py:202: test_ticket47313_final PASSED
ticket47462_test.py:230: test_ticket47462 PASSED
ticket47462_test.py:435: test_ticket47462_final PASSED
...
...
...
ticket47980_test.py:177: test_ticket47980 PASSED
ticket47980_test.py:691: test_ticket47980_final PASSED
ticket47981_test.py:216: test_ticket47981 PASSED
ticket47981_test.py:326: test_ticket47981_final PASSED

=========================================== 168 passed in 862.06 seconds =====
}}}

attachment
0001-Ticket-47999-lib389-individual-tests-not-running-cor.patch

To ssh://git.fedorahosted.org/git/389/ds.git
7c30e11..d1f75af master -> master
commit d1f75af
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Jan 23 16:50:21 2015 -0500

Fix race conditions in some of the scripts
0001-Ticket-47999-address-several-race-conditions-in-test.patch

Hello Mark,

Few comments about ticket 47721 test cases. The purpose of this ticket is to let supplier/consumer learn some definitions. This is done by internal mod that also increase the 'nsschemaCSN' on both side. The final status would be that the schema should be identical on both side and the 'nsschemaCSN' also identical.

The problem is that with this learning phase, it is difficult to predict which instance will generate the highest nsSchemaCSN. So after schema update, I would recommend to do update on both servers. So that both have the opportunity to learn and push the schema. At the end, both should contain the same nsSchemaCSN.

Especially in test_ticket47721_1 and test_ticket47721_3 , nsSchemaCSN should be != None and M1.nsSchemaCSN should be the same as M2.nsSchemaCSN.

thanks
thierry

Replying to [comment:7 tbordaz]:

Hello Mark,

Few comments about ticket 47721 test cases. The purpose of this ticket is to let supplier/consumer learn some definitions. This is done by internal mod that also increase the 'nsschemaCSN' on both side. The final status would be that the schema should be identical on both side and the 'nsschemaCSN' also identical.

The problem is that with this learning phase, it is difficult to predict which instance will generate the highest nsSchemaCSN. So after schema update, I would recommend to do update on both servers. So that both have the opportunity to learn and push the schema. At the end, both should contain the same nsSchemaCSN.

Especially in test_ticket47721_1 and test_ticket47721_3 , nsSchemaCSN should be != None and M1.nsSchemaCSN should be the same as M2.nsSchemaCSN.

Actually this is already being done:

test 1:
modify schema on m2
make user update on m2
wait for m1 to see the update

test 2:
make user update on m1
wait for m2 to see the update --> so both replica's have been updated before we check the schema CSNs
check schemaCSNs are equal

test 3:
disable repl agreement m2 -> m1
do schema update on m2
do user update on m1
schemaCSNs should be different

test 4:
do schema update on m1
do user update on m1
schemaCSNs should be the same (should be the schemaCSN from M1) since that is the only replica agreement enabled (m1 to m2)

The test appears to be working as you just described. Probably test 1 and test 2 should of been combined.

Are there any other concerns? Did I miss something?

Thanks,
Mark

thanks
thierry

Replying to [comment:8 mreynolds]:

Replying to [comment:7 tbordaz]:

Hello Mark,

Few comments about ticket 47721 test cases. The purpose of this ticket is to let supplier/consumer learn some definitions. This is done by internal mod that also increase the 'nsschemaCSN' on both side. The final status would be that the schema should be identical on both side and the 'nsschemaCSN' also identical.

The problem is that with this learning phase, it is difficult to predict which instance will generate the highest nsSchemaCSN. So after schema update, I would recommend to do update on both servers. So that both have the opportunity to learn and push the schema. At the end, both should contain the same nsSchemaCSN.

Especially in test_ticket47721_1 and test_ticket47721_3 , nsSchemaCSN should be != None and M1.nsSchemaCSN should be the same as M2.nsSchemaCSN.

Actually this is already being done:

test 1:
modify schema on m2
make user update on m2
wait for m1 to see the update

test 2:
make user update on m1
wait for m2 to see the update --> so both replica's have been updated before we check the schema CSNs
check schemaCSNs are equal

test 3:
disable repl agreement m2 -> m1
do schema update on m2
do user update on m1
schemaCSNs should be different

You are right. They should be different. Sorry for the noise

test 4:
do schema update on m1
do user update on m1
schemaCSNs should be the same (should be the schemaCSN from M1) since that is the only replica agreement enabled (m1 to m2)

Here we expect to have the same schemaCSN. So if they are not, I think the message was correct 'not in sync yet'.

Except that, the fix is good to me. Ack.

The test appears to be working as you just described. Probably test 1 and test 2 should of been combined.

Are there any other concerns? Did I miss something?

Thanks,
Mark

thanks
thierry

64e237c..18547e4 master -> master
commit 18547e4
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Jan 26 16:51:39 2015 -0500

Milestone lib389 1.0 deleted

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1330

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.