Bug 1437887

Summary: make replication conflicts transparent to clients
Product: Red Hat Enterprise Linux 7 Reporter: German Parente <gparente>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED DUPLICATE QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: mkosek, nkinder, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-06 15:38:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description German Parente 2017-03-31 12:17:37 UTC 
Description of problem:

this is just a copy of upstream bug:

https://pagure.io/389-ds-base/issue/49043

because customer wants to be updated once this bug is fixed.

Replication conflicts are created mostly because of failures in manually applying updates on different servers or client applications. But once they are created many clients, applications and users have problems to understand and handle them properly.
In most cases the "original" and "conflict" entries are identical, but there exist scenarios where both entries could have (different) children before the conflict is created, so they cannot be completely hidden or ignored.

There are several proposals to handle this, the latest: http://www.port389.org/docs/389ds/design/managing-repl-conflict-entries.html

which also discusses teh other proposals and open issues with conflict entries.

This ticket should be used to evaluate the suggested solutions and implement one, making the other tickets obsolete.
Comment 2 Martin Kosek 2017-04-03 09:56:09 UTC 
Close as a dup to Bug 1274430?
Comment 3 Nathan Kinder 2017-04-06 15:38:04 UTC 

*** This bug has been marked as a duplicate of bug 1274430 ***