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

Publish discovery information in a virtual backend, e.g. in cn=monitor


    • Type: New Feature
    • Status: Done
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 7.0.0
    • Fix Version/s: 7.0.0
    • Component/s: proxy, replication
    • Labels:


      Discovery information is required by the proxy and various tools including dsreplication status. It is read-only and not persistent. The content reacts to changes in the topology. Each server must be exposed as a separate LDAP entry containing attributes for the following meta-data:

      • Server ID
      • Group ID
      • LDAP/LDAPS address and port: may be multi-valued
      • Whether StartTLS is enabled for LDAP port
      • Admin address and port
      • Replication address and port: SSL should always be enabled. Needed for dsreplication status
      • List of replicated base DNs: may be empty in case of RS or proxy

      Each entry should be named using the server ID and possibly the group ID, i.e. using a multi-valued RDN or two levels of nesting in the LDAP hierarchy. Using the group ID for naming implies that the server ID may not be unique across a full topology. For example, it seems perfectly reasonable to name servers "ds1", "ds2", and "ds3" in each data-center, giving "groupId=new york+serverId=ds1,cn=servers,cn=monitor" or "serverId=ds1,groupId=new york,cn=servers,cn=monitor".

      There may be multiple LDAP listeners and each may support SSL or StartTLS, which requires a complex syntax. We could use LDAP URLs (RFC 4516) allowing us to specify whether SSL is enabled via the URL schema "ldaps". Unfortunately, there is no standard way to represent StartTLS in URLs: we could use extensions or simply invent our own scheme for our purposes such as "ldapq" ("q" being the flag which enables StartTLS in our tools).

      The schema must be extensible and components and tools that query it must be forwards compatible by tolerating unrecognized attributes. In future, we may publish partition IDs and other meta-data, such as identifiers relating to sovereignty.

      A standalone server which is not part of a replication topology should also publish discovery information. From an implementation point of view this implies that discovery information should be managed outside of the replication code, but driven by replication events.

      It is probably easiest to publish this data in cn=monitor - we already do this for certificate meta-data. The content will depend on replication for distributing discovery information. For example, when a DS connects to an RS it includes the above meta-data in its handshake. The RS then forwards the information to the rest of the topology. Likewise, when a DS disconnects the RS publishes a disconnect (offline) event across the topology. Note that a joining DS will need to be sent meta-data for the whole topology. It looks like replication's TopologyMsgs are a good fit.

      Note: a proxy could also provide discovery information by joining a replication topology but choosing not to replicate any base DNs.


          Issue Links



              • Assignee:
                cforel carole forel
                matthew Matthew Swift
                Dev Assignee:
                Jean-Noël Rouvignac
                QA Assignee:
                carole forel
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: