[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3979) glue mixtures can confuse slapadd

Hallvard B Furuseth wrote:
Howard Chu writes:
Perhaps it was a mistake to remove the OpenLDAP 2.2 "subordinate"
config syntax, as that usage would have prevented this type of
configuration from occurring. Maybe we should add the old syntax back
in, and have the overlay automatically inserted, like some of the
others do?

Should be OK either way as long as bad configuration gives a useful
error message. I do feel it fit better to specify the gluing in the
subordinate database than in the root database, but that's just my
personal preference.
I'll work on restoring the 2.2 syntax. The other thing that bothered me was that glue was a core feature in 2.2 and in 2.3 it is optional and may be disabled. It should have remained a core feature (regardless of how the implementation was refactored).
(If "subordinate" is added back, I presume it would need the
async and advertise optional parameters that "glue-sub" accepts.)
Yes. Although "async" is still unimplemented, and I'm wondering if it is useful in its present definition. Given the need to enforce sizelimits, I don't think it's desirable to immediately fan out a search across all the subordinates. The search must be deterministically sequenced (top-down, breadth-first, whatever) so that two identical search requests with the same sizelimit return the identical result set, otherwise I think we'd break the data model. Most likely all mention of "async" should just be deleted.

On a slightly related topic, I do think it's desirable to be able to configure multiple subordinates as fractional peers, because that would be a big help for scaling. (I.e. multiple backends with the same suffix, each only responsible for a portion of the total content.) We might support this by adding an additional filter specifier to identify which backend is responsible for a given entry. Ideally the specifier would only depend on the entry's RDN, so that select_backend's signature remains unchanged. e.g.:

# all entries from uid=a*,ou=users,o=org to uid=f*,ou=users,o=org
database bdb
subordinate (uid<=f*)
suffix ou=users,o=org
...

# all entries from uid=g*,ou=users,o=org to uid=m*,ou=users,o=org
database bdb
subordinate (uid<=m*)
suffix ou=users,o=org
...


Unfortunately a simple scheme like this requires constant monitoring and frequent rebalancing. A better scheme would be to hash the DN and evenly distribute entries among all the peers. I guess we could hack this into a filter by creating a custom matching rule... 
   database  bdb
   suffix    cn=kids,cn=people,dc=uio,dc=no
   directory /tmp/db/kids

   # Does not support slapadd/slapcat
   database  ldap
   suffix    cn=people,dc=uio,dc=no
   uri       ldap://ldap.uio.no/
   overlay   glue
   glue-sub  cn=kids,cn=people,dc=uio,dc=no

database bdb
suffix dc=uio,dc=no
directory /tmp/db/uio
overlay glue
glue-sub cn=people,dc=uio,dc=no



--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/