Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-5012

Replication: reset-change-number fails when DS exposes different public naming contexts (replicated or not)

    Details

    • Type: Bug
    • Status: Done
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.0
    • Fix Version/s: 6.5.0
    • Component/s: None
    • Epic Link:
    • Story Points:
      1
    • Support Ticket IDs:

      Description

      EDIT: We had same issue https://bugster.forgerock.org/jira/browse/OPENDJ-4725 but looks like upgrade task is missing.


      Found using 6.0.0-RC2 and upgrade job.

      The test use upgraded instances (we install 3 servers with version 5.0.0 and we upgrade them all) and after 2 instances are added to replication topology.
      After adding 3rd DSRS instance to existing topology it is not possible to reset change number.
      A command to reset change number returns RC 38 with a message:

      Cannot reset change-log change number because replicated baseDNs on server
      pyforge.example.com:4444 and server pyforge.example.com:4446 differ. Since the
      change number is computed across all the replicated baseDNs, the change-log
      change number can only be reset between two replication servers replicating
      the exact same baseDNs.
      

      Looking at baseDNs on all 3 instances they are same, so the message doesn't look correct.

      The same test works if we use the 6.0.0-RC2 from start of the test (no upgrade before configuration of replication).

      I compared backends in both cases (with upgrade and without) and I noticed that we have a small difference in backends list:

      Backend        : Type        : enabled : base-dn                : confidentiality-enabled
      ---------------:-------------:---------:------------------------:------------------------
      adminRoot      : ldif        : true    : cn=admin data          : -
      ads-truststore : trust-store : true    : -                      : -
      backup         : backup      : true    : -                      : -
      monitor        : monitor     : true    : -                      : -
      monitorUser    : ldif        : true    : uid=Monitor            : -
      rootUser0      : ldif        : true    : cn=myself              : -
      schema         : schema      : true    : -                      : -
      tasks          : task        : true    : -                      : -
      userRoot       : je          : true    : dc=com, dc=othersuffix : false
      

      vs

      Backend        : Type        : enabled : base-dn                : confidentiality-enabled
      ---------------:-------------:---------:------------------------:------------------------
      adminRoot      : ldif        : true    : cn=admin data          : -
      ads-truststore : trust-store : true    : -                      : -
      backup         : backup      : true    : -                      : -
      monitor        : monitor     : true    : -                      : -
      monitorUser    : ldif        : true    : uid=Monitor            : -
      rootUser       : ldif        : true    : cn=myself              : -
      schema         : schema      : true    : -                      : -
      tasks          : task        : true    : -                      : -
      userRoot       : je          : true    : dc=com, dc=othersuffix : false
      

      We have a rootUser0 with upgraded instance and rootUser without upgrade.

      We had same issue with OPENDJ-4725 which is fixed and verified, but the upgrade is not covered.

        Attachments

          Activity

            People

            • Assignee:
              joseph.de-menditte Joseph de-Menditte
              Reporter:
              ondrej.fuchsik Ondrej Fuchsik
              QA Assignee:
              Ondrej Fuchsik
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: