Upstream ticket:
https://fedorahosted.org/389/ticket/160

Hi Martin and Simo,

I've summarized the conflict/tombstone entry related changes to be made on this wiki page:
http://directory.fedoraproject.org/wiki/Separate_Conflict_and_Tombstone_Entry

Could you please take a look and give me your comments?

Thanks!
--noriko

I read the proposal and saw the 2 approaches about how to address the issue, the first one seemed to be as the preferred one as it was described in a more detailed way.

However, the first approach mainly looks like an internal change - AFAIU, the only change we would see from IPA side is that the conflicting entry would now have a new object class "nsConflict" and nsdsEntryType attribute filled.

I assume this would still disrupt IPA operations (like user-add described in Bug 772294), as reported in the following IPA Bugs: Bug 772294, Bug 695797.

Our target was an ability of the DS to move the conflicting entries out of the IPA DIT tree so that they don't conflict with IPA operations, i.e. the second approach you mentioned on the design page. Then, we would provide users with tools to check and handle the conflicting entries.

Simo, did I miss anything?

(In reply to comment #4)

> Simo, did I miss anything?

I think you did, my understanding is that with the first proposal a client will never see conflict or thombstone entries unless you explicitly search for their objectlasses in the filter, ie (objectclass=*) would not match them.
That solves the problem for us as normal clients will not see those entries and we can provide tools to search for conflicts by simply searching for the correct objectclass.

Noriko, please correct me as well :-)

Ah, Simo thanks for clarification. If this is the case, that would actually make more sense to me and would be usable by IPA too. Such solution would be even more convenient for managing as we would not have to control the new suffixes.

Thanks a lot, Martin and Simo.  Yes, your observation/understanding is correct, Simo.  Unless you add "(objectclass=nsTombstone)" or "(objectclass=nsConflict)", you won't see the tombstone entry or the conflict entry, respectively.

Sorry about the memo.  It's mainly for myself to start implementing... :)

I'd like to suggest a third approach.

We always try to reconcile replication conflicts as far as possible, only in the case where two entries are generated with the same dn on different servers we give up completely. In my opinion most of the cases are because a client sends an ADD two multiple servers, an in these cases the enries would be identical.

My suggestion is to merge the conflicting entries into one, keeping the conflict invisible for clients in an generated attribute with subtypes, eg:

replconflict;<nsuniqueid>;<attrname>: value

Normal clients would see one entry, an administrator could request the conflict attr and resolve a conflict, maybe just delete replconflict;<nsuniqueid>;

Ludwig,
in the case of FreeIPA ehrn creating users, due to the use of the DNA plugin, in most cases the 2 entries would have conflicting uidNumber and gidNumber (and also ipaUniqueId and other minr stuff).
How do you propose merging the entries in this case ?

Simo.

(In reply to comment #9)
> Ludwig,
> in the case of FreeIPA ehrn creating users, due to the use of the DNA
> plugin, in most cases the 2 entries would have conflicting uidNumber and
> gidNumber (and also ipaUniqueId and other minr stuff).
> How do you propose merging the entries in this case ?

That's not a replication conflict, so it would have to be handled in a different manner.

> 
> Simo.

This is not going to be addressed for RHEL 7.1.  Changing the flags to target RHEL 7.2.

Per 7.3 triage:
> This is old, but it comes up every now and then.  For now, IdM should probably search for conflicts and mention them on the replication monitoring UI (which needs to be developed).

Pushing to post 7.3.

There is no post 7.3 in pm-rhel flag yet...
Stay in 7.3 until 7.4 is ready.

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