Add an assertion that user_num != new_num so that it's clear that a change has to occur?

Why do you need a sleep?

Given this logic and the end you have a resume + test_replica, you don't need any sleeps on create/rename user.

you need the sleeps to ensure that in each run really the same csn order is generated for the operations. In csn comparison you compare the time stamp and sequence number and if they are identical you compare the replicaid.

So if you run

op1(m2)
op2(m1)
you expect that op1 gets the smaller csn, but in fact if both ops are done in the same second op2 might have the smaller csn.

For a general replication test this wouldn't matter, just ensure that replication is working. But for conflict tests the test scenario are designed to execute a specific order and we need to eliminate random order.

Can this be a python enum instead perhaps?

Really not sure how I feel about this method. It's a bit of a dangerous one, and has really limited use generally as an API. As well you only use it during test finalisation. A better idea could be to limit this to specifically the container type (to enable it to be deleted cleanly), to mark it private (_delete_tree). I'll need to think about it a bit to really know to comment on it properly.

you need the sleeps to ensure that in each run really the same csn order is generated for the operations. In csn comparison you compare the time stamp and sequence number and if they are identical you compare the replicaid.

So if you run
op1(m2)
op2(m1)
you expect that op1 gets the smaller csn, but in fact if both ops are done in the same second op2 might have the smaller csn.

For a general replication test this wouldn't matter, just ensure that replication is working. But for conflict tests the test scenario are designed to execute a specific order and we need to eliminate random order.

Thank you for the review!
I've added the check to _rename_user function and I've added enum log levels.

Regarding the sleeps, Ludwig has explained his point. We need it for this particular test case.

And about delete_tree method. I agree that it is a dangerous method and we need to think about it carefully.
My arguments for keeping it:
- We need it in API not only for containers but also for organizational units, domains, and organizations.
- It still can be useful for the end user (for instance, ldapdelete has the '-r' functionality).

I think we can add additional warnings for the CLI usage.
And for API, we can still use it for DSLdapObject when we need it.

Add a filterstr option for delete_branch_s. The 'delete_tree' uses "(|(objectclass=*)(objectclass=ldapsubentry))" now.

I've fixed issues mentioned by Ludwig: https://pagure.io/389-ds-base/issue/49551#comment-493717

And @firstyear , I removed delete_tree() method. I've moved the functionality to the test suite because it makes more sense to have it there.

Why do you need a sleep here?

Besides the time.sleep(1) you have in here, I'm happy with this. What purpose does the time.sleep here serve? You either need to wait for replication, or you don't need it :)

I tried to explain the need for sleeps ih a comment 16 days ago. It is to ensure the same order of of csns in each run. Since replication is disabled in most of the actions we cannot wait for replication

but, this is needed only when switching from one master to another, not for consecutive changes on the same master. (in my original test had a sleep argument, which was false by default)

I've put the sleeps as you said, @lkrispen

By the way, in the test suite for two masters, you have sleep=True by default...
https://pagure.io/389-ds-base/issue/raw/00571921ea43decbc7d643449783871aefe323fd3c314427161fb228dc22a463-ticket49043_1_test.py

ok for me

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/2617

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.