https://bugzilla.redhat.com/show_bug.cgi?id=507745
Description of problem: some entries do not seem to be replicating when they should be in reliab20 env 20 masters Of the replication agreements in this particular environment, two exist that replicate master 4 and master 9. They are called M4M9 and M9M4 10 entries are created on a replicate suffix on M9. 9 of the entries get there. One does now. Version-Release number of selected component (if applicable): redhat-ds-base-8.1.0-0.10.el5dsrv How reproducible: unknown Actual results: The entry does get into M9, but never seems to make it to M4. The csn of the entry in question seems to be: csn=4a4148d10000000a0000 The ruv of the agreement appears to be: nsds50ruv: {replica 9 ldap://mach1.idm.lab.bos.redhat.com:38008} 4a4148d0000400090000 4a4156cc000000090000 Additional info: I'm trying to recreate the bug more reliably, and quickly now. The current logs are VERY large, and a bit difficult to go through.
Closing per 01/23 ds weekly meeting. Invalid. Will run Rel20 and reassess.
Added initial screened field value.
Metadata Update from @shaines: - Issue set to the milestone: N/A
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/212
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.