Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

So, for a key path production/app1/key1 the key/value pair could be found at the DN simpkvKey=key1,ou=app1,ou=production,ou=environments,<root DN for the backend instance>, where simpkvKey is an attribute of a simpkvEntry LDAP object used to store the key/value pair. Visually, this subtree in the DIT would look something like the following:

...

Below is an example of the DIT in which simpkvEntry is a custom LDAP object class with simpkvKey and simpkvJsonValue attributes holding the key and value, respectively:

...

simpkv Subtree Option 2

The second design option enforces DN case invariance without impacting the existing simpkv API. In this design, . Its simpkv subtree has the same layout as that of Option 1, including the use of the ‘instances’, 'globals', and ‘environments’ grouping “folders”. However, in this design the LDAP plugin transforms any problematic attributes that are to be used in a DN for a key/value pair to an encoded representation (e.g., hexadecimal, Base 64) . For example, with a hexadecimal transformation, all backend instance identifiers, key names, and folder names would be represented in hex, minus the ‘0x’ or ‘0X’ preface**. This means So, key paths production/app1/key1 and production/App1/Key1 are would be mapped to
simpkvHexId=61707031,simpkvHexId=6b657931,ou=production,ou=environments,...
and
simpkvHexId=41707031,simpkvHexId=4b657931,ou=production,ou=environments,....

which although not human-friendly are definitely unique.

As with Option 1, the proposed simpkv LDAP subtree

Then, in order to support standard
respectively, where simpkvHexId is an attribute of both a simpkvFolder LDAP object used to represent backend identifiers/folders and a simpkvEntry LDAP object used to store the key/value pair.

**Puppet environment names are not allowed to include uppercase letters.

In addition, in this design each node with an encoded identifier in its RDN in would contain an attribute with the raw identifier.

  • This additional information is necessary in order to support external searches of the LDAP tree using the raw backend instance identifiers, key names, and folder names

...

In addition, to facilitate searching of the LDAP by their original

...

  • .

  • Some ‘OrganizationalUnits’ in Option 1 would now be represented by a custom object that had encoded and raw identifier attributes.

  • The custom class for the key/value nodes would have encoded and raw key attributes.

Below is an example of the DIT in which

  • simpkvFolder is a custom LDAP object class with simpkvHexId and simpkvId attributes holding the transformed backend identifier/folder and raw identifier/folder, respectively

  • simpkvEntry is a custom LDAP object class with simpkvHexId, simpkvId and simpkvJsonValue attributes holding the transformed key, raw key and value, respectively.

Recommendation

Schema and OID Subtree Design

...