Bug 813157

Summary: Replication problems:when you create a HUB replica and it modified to Supplier then the RUV/replica id details were not updated in the db/memory
Product: [Retired] 389 Reporter: rajendra <rajendra.babu>
Component: Replication - GeneralAssignee: Rich Megginson <rmeggins>
Status: CLOSED NOTABUG QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: unspecified    
Version: 1.2.0CC: benl, nhosoi
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Other   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-21 21:10:05 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:
Attachments:
Description Flags
The attachment has having in details description of the problem and reproduce steps none

Description rajendra 2012-04-17 06:02:54 UTC
Created attachment 577884 [details]
The attachment has having  in details description of the problem and reproduce steps

Description of problem:

We have noticed two problems in the multiimaster replication environment of 389-1.2.0 code Base.  Here are the details below.
Problem 
=========
When the replica is modified (role change from HUB to Supplier), the replica id is updated from 65535 to newly given replica id (Ex: 15151) in the dse.ldif file. But the RUV entry in the db/memory still having the old replica id (i.e 65535 ) instead of newly provided replica id. This caused the following problems:

1.	Supplier and consumer still having the old replica ID (65535).
2.	The replication to the consumer always starts from the Min CSN and   supplier pushes all the entries from starting (If an entry is already replicated, the consumer just ignores it). Hence you can notice multiple log entries for a single operation in the access log. 
3.	Since the replication to consumer always starts from Min CSN, the new entries get replicated only after processing all old entries which would lead to delay in replication of new entries.

Kindly refer the attached document for more details .

Version-Release number of selected component (if applicable):

389-1.2.0 code Base.  

How reproducible:

Kindly refer the Attached document 


Actual results:

1) When the replica is modified (role change from HUB to Supplier),  the  Supplier and consumer still having the old replica Id insted of newly creaed Replica id in the db/memory.

2) Noticed multiple logs for single MOD operation in Access log.

Expected results:

1) When the replica is modified (i.e Role change from HUB to Supplier), the RUV entry in the db/memory needs to be updated with modified replica Id (i.e which is Supplier replica id)

2) There should not be multiple entries for single MOD operation in access logs

Comment 1 Rich Megginson 2012-04-17 13:18:13 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/341

Comment 2 Noriko Hosoi 2012-04-19 20:44:15 UTC
Did you have a chance to see this bug 750425 filed by Jyoti ranjan das (jyoti-ranjan.das)?

https://bugzilla.redhat.com/show_bug.cgi?id=750425

The fix is in 389-ds-base-1.2.10 and newer.

Is it possible to try the reproducer steps with the version?

Comment 3 Noriko Hosoi 2012-05-21 21:10:05 UTC
(In reply to comment #2)
> Did you have a chance to see this bug 750425 filed by Jyoti ranjan das
> (jyoti-ranjan.das)?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=750425
> 
> The fix is in 389-ds-base-1.2.10 and newer.
> 
> Is it possible to try the reproducer steps with the version?

Since we did not hear from you longer than a month, we are closing this bug for now.  Please feel free to reopen it once you get the information we asked for.
Thanks.