ldap/core deleteTree not always supported

[Richard Megginson]

Not every LDAP server supports CONTROL_TREEDELETE (OID 1.2.840.113556.1.4.805)
e.g. openldap, 389
The LDAP server will respond with ldap.NOT_ALLOWED_ON_NONLEAF in that case, and
the client will have to fallback on a recursive delete (note this is what openldap
ldapdelete -r does).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/74897

[Brant Knudson (blk-u)]

Keystone has an option

 [ldap]
 allow_subtree_delete = false

That means that the Keystone server shouldn't be making subtree deletes.

So this seems to be working as designed.

[Richard Megginson (rmeggins)]

Ok. Would you guys rather just permanently disallow ldap subtree delete with the config option, or would you rather I keep going and do the deletion sorted by the length of the DN rather than by the reverse() of the entry list?

[Brant Knudson (blk-u)]

Looks like the documentation could be improved: http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n791 . I submitted a change that I think improves the documentation: https://review.openstack.org/#/c/78497/

So I think this is working as designed.

[Dolph Mathews (dolph)]

Should this be closed? Code review is abandoned and I'm not sure why Brant didn't change the bug status here?

[Richard Megginson (rmeggins)]

Why is the status Incomplete?

[Dolph Mathews (dolph)]

As described above, I'm not clear on whether this should remain as an open issue or not.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/74897
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=519161422dab4c25df79b6d4db35f7613847afd6
Submitter: Jenkins
Branch: master

commit 519161422dab4c25df79b6d4db35f7613847afd6
Author: Rich Megginson <email address hidden>
Date: Wed Feb 19 17:56:55 2014 -0700

    ldap/core deleteTree not always supported

    Most LDAP servers do not support CONTROL_TREEDELETE
    (OID 1.2.840.113556.1.4.805) e.g. openldap, 389, and many others.
    The LDAP server will respond with ldap.NOT_ALLOWED_ON_NONLEAF
    in that case, and the client will have to fallback on doing an
    LDAP search to get the list of entries to delete, then deleting
    the entries in order of child to parent, since LDAP forbids the
    deletion of a parent entry which has children. The simplest way
    to generate a child to parent ordering is to delete the entries
    in the order of the length of the DN, from longest to shortest.

    Closes-Bug: #1282355

    Change-Id: I3f08cc4bc890eec9f91945941c3636cb0b30658a