Bug 578167

Summary: repl. of mod/replace deletes multi-valued attrs
Product: [Retired] 389 Reporter: Rich Megginson <rmeggins>
Component: Replication - GeneralAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 1.2.6CC: andrey.ivanov, jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 17:00:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434914, 543590    
Attachments:
Description Flags
0001-Bug-578167-repl.-of-mod-replace-deletes-multi-valu.patch nkinder: review+

Description Rich Megginson 2010-03-30 13:22:18 UTC 
When a mod/replace operation is replicated, it can cause the consumer to delete the attribute instead.

Steps:
create two masters m1 and m2
set up agreements between m1 and m2 both ways
verify replication is working
stop replication (set agmt nsds5replicaupdateschedule to "2358-2359 0")
do a mod/replace of "description" with value "desc 0" to m2
wait 5 seconds
do a mod/replace of "description" with value "desc 1" to m1
wait 2 seconds
do a mod/replace of "description" with value "desc 2" to m1

restart replication (set agmt nsds5replicaupdateschedule to "0000-2359 0123456")

What should happen is that the value of the description attribute is "desc 2" since that value has the latest csn - but the bug causes the description attribute to be deleted.  A search for the attribute nscpEntryWsi shows this:
nscpEntryWsi: description;adcsn-4bb1f944000000010000;vucsn-4bb1f942000000010000;deletedattribute;deleted: description 1
nscpEntryWsi: description;vucsn-4bb1f944000000010000;deletedattribute;deleted: description 2
nscpEntryWsi: description;vucsn-4bb1f93e000000020000;deletedattribute;deleted: description 0

The deletedattribute means the attribute was deleted.
Comment 1 Andrey Ivanov 2010-03-30 19:17:25 UTC 
There was sort of a similar bug - 515329. Don't know if they could be of the same type/origin.
Comment 2 Rich Megginson 2010-03-30 22:04:02 UTC 
Created attachment 403607 [details]
0001-Bug-578167-repl.-of-mod-replace-deletes-multi-valu.patch
Comment 3 Rich Megginson 2010-03-30 22:54:08 UTC 
To ssh://git.fedorahosted.org/git/389/ds.git
   6e839e9..c559982  master -> master

commit c559982cddbe09bad1b7717a84c7b0187111d61a
Author: Rich Megginson <rmeggins>
Date:   Tue Mar 30 16:01:58 2010 -0600
    Reviewed by: nkinder (Thanks!)
    Branch: HEAD
    Fix Description: The server implements a mod/replace operation as a
    mod/delete if all values, followed by a mod/add of the new values.  The
    mod/delete phase, since it removes all of the values, essentially deletes
    the attribute, so it must set the attribute deletion_csn.  This is even
    true in the case when you do a mod/replace on an attribute that doesn't yet
    exist.  We have to create an empty attribute on the deleted_attrs list with
    the deletion_csn set to the csn of the operation.  This preserves the
    semantics of the mod/replace operation.
    When doing the add phase of the mod/replace, we have to be able to
    resurrect attributes and values that may have been deleted by the mod/delete
    phase.  We can tell that we need to resurrect a deleted value in
    resolve_attribute_state_multi_valued, in the deleted_values loop, because
    the deletioncsn will be the same as the update csn, and the
    delete_priority flag will be 0.
    Platforms tested: RHEL5 x86_64
    Flag Day: no
    Doc impact: no

To ssh://git.fedorahosted.org/git/389/ds.git
   6dec072..71b5bb9  Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch
commit 71b5bb925a53ecdc23c584eca9fcc4a86093b7cf
Author: Rich Megginson <rmeggins>
Date:   Tue Mar 30 16:01:58 2010 -0600
    Branch: Directory_Server_8_2_Branch
Comment 4 Jenny Severance 2010-05-19 20:07:26 UTC 
fix verified RHEL 4

version:
redhat-ds-base-8.2.0-2010051904.el4dsrv

With Replication stopped:
On server 2: changed description to "desc 0"
On server 1: changed description to "desc 1" and then to "desc 2"

[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 0


After Replication restarted:
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2
Comment 5 Rich Megginson 2010-11-20 01:00:26 UTC 
This is closely related to bz515329