Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause: If you just setup replication agreements, without initializing the consumers, the status message makes it appear that replication is running successfully when in fact it has not started.
Consequence: The replication status attributes do not report the expected results as no updates have actually been sent.
Fix: Improved when the status messages are updated.
Result: The replication status messages are correct, and not misleading.
Description of problem:
Assume single master - single consumer replication
Before replication can work, consumer must be initialized. When creating replication agreement, user can select "Do not initialize consumer", which should leave consumer uninitialized and replication not working after agreement is created. However, master still needs to query consumer to find out whether consumer has been initialized yet.
In this setup, 3 attributes (nsds5replicaLastUpdateStart, nsds5replicaLastUpdateEnd, nsds5replicaLastUpdateStatus) tracking status of replication agreement show incorrect data:
-nsds5replicaLastUpdateStart/nsds5replicaLastUpdateEnd show when was the last time master has checked consumer status (NOT when was the last time update happened)
- nsds5replicaLastUpdateStatus shows "0 Replica acquired successfully: Incremental update started", which is not true, since replication is not working (update has not started)
Version-Release number of selected component (if applicable):
redhat-ds-9.1.0-1.el6.i386 on RHEL 6.4
How reproducible:
always
Steps to Reproduce:
1) Configure single master-single consumer replication and do not initialize consumer. Because consumer is not initialized, replication is not working and no updates are sent.
2) Check replication agreement entry:
dn: cn=test3,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
description: test3
cn: test3
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost: dstet.example.com
nsDS5ReplicaPort: 2389
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: {DES}3iMsHyML5/QgiI3nMoqaYw==
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20130319124248Z
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update started
nsds5replicaUpdateInProgress: TRUE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
Note that this search was performed *exactly* when master checked consumer, so there is no LastUpdateEnd and update is in progress (nsds5replicaUpdateInProgress: TRUE). However, usually master checks every 3 seconds, and nsds5replicaLastUpdateStart and nsds5replicaLastUpdateEnd change to reflect this.
Actual results:
nsds5replicaLastUpdateStart and nsds5replicaLastUpdateEnd track the time when master checked consumer, not the last time update happened.
Expected results:
nsds5replicaLastUpdateStart should be 0
nsds5replicaLastUpdateEnd should be 0
nsds5replicaLastUpdateStatus should not say "Incremental update started" when it hasn`t
Additional info:
moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata). When the errata is created, the bugs should be automatically moved back to ON_QA.
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
Description of problem: Assume single master - single consumer replication Before replication can work, consumer must be initialized. When creating replication agreement, user can select "Do not initialize consumer", which should leave consumer uninitialized and replication not working after agreement is created. However, master still needs to query consumer to find out whether consumer has been initialized yet. In this setup, 3 attributes (nsds5replicaLastUpdateStart, nsds5replicaLastUpdateEnd, nsds5replicaLastUpdateStatus) tracking status of replication agreement show incorrect data: -nsds5replicaLastUpdateStart/nsds5replicaLastUpdateEnd show when was the last time master has checked consumer status (NOT when was the last time update happened) - nsds5replicaLastUpdateStatus shows "0 Replica acquired successfully: Incremental update started", which is not true, since replication is not working (update has not started) Version-Release number of selected component (if applicable): redhat-ds-9.1.0-1.el6.i386 on RHEL 6.4 How reproducible: always Steps to Reproduce: 1) Configure single master-single consumer replication and do not initialize consumer. Because consumer is not initialized, replication is not working and no updates are sent. 2) Check replication agreement entry: dn: cn=test3,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement description: test3 cn: test3 nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaHost: dstet.example.com nsDS5ReplicaPort: 2389 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaTransportInfo: LDAP nsDS5ReplicaBindMethod: SIMPLE nsDS5ReplicaCredentials: {DES}3iMsHyML5/QgiI3nMoqaYw== nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20130319124248Z nsds5replicaLastUpdateEnd: 0 nsds5replicaChangesSentSinceStartup: nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update started nsds5replicaUpdateInProgress: TRUE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 Note that this search was performed *exactly* when master checked consumer, so there is no LastUpdateEnd and update is in progress (nsds5replicaUpdateInProgress: TRUE). However, usually master checks every 3 seconds, and nsds5replicaLastUpdateStart and nsds5replicaLastUpdateEnd change to reflect this. Actual results: nsds5replicaLastUpdateStart and nsds5replicaLastUpdateEnd track the time when master checked consumer, not the last time update happened. Expected results: nsds5replicaLastUpdateStart should be 0 nsds5replicaLastUpdateEnd should be 0 nsds5replicaLastUpdateStatus should not say "Incremental update started" when it hasn`t Additional info: