Bug 514955

Summary: Replica assigns new value from local range when replace is performed with magic value
Product: [Retired] 389 Reporter: Nathan Kinder <nkinder>
Component: Server - DNA Plug-inAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2.1CC: jgalipea, rmeggins
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 16:49:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 434914, 517385    
Attachments:
Description Flags
Patch
none
Revised Patch none

Description Nathan Kinder 2009-07-31 16:17:37 UTC
When using DNA with replication, replacing an existing managed value with the magic value causes all replicas to assign a new value from their local range.  The first server should assign the value, which should then be replicated to all other replicas.

To reproduce:

  - Setup replication with 2 masters.
  - Enable the DNA plug-in on both masters.
  - Add the following shared configuration container:

       dn: ou=ranges,dc=example,dc=com
       objectclass: top
       objectclass: organiationalUnit
       ou: ranges

  - Add the following range configuration entries to the appropriate master:

    M1:
       dn: cn=testrange,cn=Distributed Numeric Assignment
        Plugin,cn=plugins,cn=config
       objectclass: extensibleObject
       dnamaxvalue: 1010
       dnamagicregen: 0
       dnathreshold: 1
       dnatype: uidNumber
       dnafilter: (objectclass=posixAccount)
       dnascope: dc=example,dc=com
       dnasharedcfgdn: ou=ranges,dc=example,dc=com
       dnanextvalue: 1001

    M2:
       dn: cn=testrange,cn=Distributed Numeric Assignment
        Plugin,cn=plugins,cn=config
       objectclass: extensibleObject
       dnamaxvalue: 1020
       dnamagicregen: 0
       dnathreshold: 1
       dnatype: uidNumber
       dnafilter: (objectclass=posixAccount)
       dnascope: dc=example,dc=com
       dnasharedcfgdn: ou=ranges,dc=example,dc=com
       dnanextvalue: 1011

  - Perform the following operation against M1:

       dn: uid=testuser,dc=example,dc=com
       changetype: add
       objectclass: posixAccount
       objectclass: inetorgperson
       cn: testuser
       sn: testuser
       homedirectory: /home/test    
       gidnumber: 1

  - At this point, the entry should have a uidNumber value of 1001 on
    both masters.

  - Perform the following operation against M1:

       dn: uid=testuser,dc=example,dc=com
       changetype: modify
       replace: uidNumber
       uidNumber: 0

  - At this point, the uidNumber will be 1002 on M1 and 1011 on M2.  The
    value is supposed to be 1002 on both servers.

Comment 2 Nathan Kinder 2009-07-31 22:14:57 UTC
Created attachment 355867 [details]
Patch

Comment 3 Nathan Kinder 2009-08-03 16:08:30 UTC
Created attachment 356057 [details]
Revised Patch

The previous patch did not handle all cases.  This new patch takes a different approach than the previous patch.  Instead of trimming the mod that triggered generation, we leave it alone and make DNA check subsequent mods before commiting to generating a new value.  This is easily done by just unsetting the generate flag if we find a subsequent mod for the same attribute in the same operation.

Comment 4 Nathan Kinder 2009-08-03 17:04:34 UTC
Pushed patch from comment#3 to master.  Thanks to Noriko for her review!

Comment 5 Jenny Severance 2010-06-02 13:44:59 UTC
verified - All DNA acceptance tests passing at 100% - all supported platforms