#49658 In repicated topology a single-valued attribute can diverge
Closed: wontfix 5 years ago by tbordaz. Opened 6 years ago by tbordaz.

Issue Description

On a replicated topology with more than 2 server, a single value attribute can be present (with a given value) on some instances and can be deleted on some others.

This happens if several update lead to the same value of the attribute but are replicated in a different order.

Package Version and Platform

At least since 1.3.7

Steps to reproduce

Testcase provided

Actual results

The attribute can be deleted or present depending of the server

Expected results

The attribute value should be identical on all servers


Metadata Update from @tbordaz:
- Issue assigned to tbordaz

6 years ago

Metadata Update from @tbordaz:
- Custom field component adjusted to None
- Custom field origin adjusted to IPA
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

6 years ago

The test works. Thank you!

We need to improve the code so it uses the current modules and has proper docstrings.

First, please, fill all the docstring fields. You can refer to 5th step from here:
https://fedorapeople.org/~spichugi/html/guidelines.html
(basically, you need to specify the first line, id and expectedresults)

 """Specify a test case purpose or name here

:id: 0
:setup: 3 Master Instances
:steps:
    1. Create 3 suppliers
    2. Create on M3 a test entry having a single-value attribute employeeNumber=11
        and update it MOD_DEL 11 + MOD_ADD 12
    3. Check it is replicated on M1 and M2
    4. Isolate M1 and M2 by pausing the replication agreements
    5. On M1 do MOD_DEL 12 + MOD_ADD_13
    6. On M2 do MOD_DEL 12 + MOD_ADD_13
    7. Enable replication agreement M2 -> M3, so that update step 6 is replicated first
    8. Enable replication agreement M1 -> M3, so that update step 5 is replicated second
    9. Check that the employeeNumber is 13 on all servers
:expectedresults:
    1. Fill in the result that is expected
    2. For each test step
"""

Another thing, we should put the new tests to dirsrvtests/tests/suite/ directly. We will port everything from tickets eventually. I think you can put it to replication/regression_test.py but it is up to you. And you need to rename the function name (not 'def test_ticket49658' but something that describes the test).

And the last thing but not least, please, check this page:
https://fedorapeople.org/~spichugi/html/cheatsheet.html#agreements-and-pausing-replication
and replace your agreement methods with one of these (or both, depending on the purpose). We should not use the old API, it will be deprecated in the future.

from lib389.replica import ReplicationManager

repl = ReplicationManager(DEFAULT_SUFFIX)

# Pause/resume one replica direction
repl.disable_to_master(to_instance=M3, from_instances=[M1, M2])
repl.enable_to_master(to_instance=M3, from_instances=[M1, M2])

# Pause/resume all replication in the topology
topology_m4.pause_all_replicas()
topology_m4.resume_all_replicas()

I will update the page in the future if any concerns about old/new API will rise.

The attached patch fixes the testcase but it needs additional tests with different order of operations

More test coverage. It is missing the test of distinguished single valued attribute

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0

6 years ago

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1600631

5 years ago

During the review https://pagure.io/389-ds-base/issue/49658#comment-512146, @lkrispen suggested that the fix added a new specific case handling to the single_value resolution algo.
This was right. We agreed to try a full rewrite to make the single_value resolution algo more understandable.

The test suite is improved and the rewrite code are available in
https://pagure.io/389-ds-base/pull-request/50132

The test list will eventually merge with replication test suite

24271fe..e09725e master
98bfccc..70cac1b 389-ds-base-1.4.0
50240de..4c71cc2 389-ds-base-1.3.9
26517ea..81ce57b 389-ds-base-1.3.8
1b193a1..407e89e 389-ds-base-1.3.7

Metadata Update from @tbordaz:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

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/2717

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Log in to comment on this ticket.

Metadata