feature: identity-backend subordinate relation for v3 domains

[Matt Rae]

Currently the keystone charm has options to configure an ldap backend for identity. When enabling keystone v3, it is also possible to enable backends per domain. Requesting a feature to allow configuring the identity backend for domains.

/etc/keystone/keystone.conf:
[identity]
domain_specific_drivers_enabled = True

Then for the domain (DOMAIN_NAME) we want to use ldap as a backend, create the file:

/etc/keystone/domains/keystone.DOMAIN_NAME.conf

This can include [ldap] section which defines the ldap configuration for this domain

http://docs.openstack.org/admin-guide/identity-integrate-identity-backend-ldap.html

[James Page (james-page)]

We should support additional domain backends using subordinate charms, and a new container scoped relation on the keystone charm

This would allow different LDAP/<insert backend here> backends to be configured and integrated in the same keystone installation.

[Benjamin Kaehne (ben-kaehne)]

Hello,

We currently have this as a local configuration to the latest keystone charm and would be keen to see what this looks like (and implement over our local modifications) when it is released.

[Frode Nordahl (fnordahl)]

There should be a upgrade path for existing users of charm configured LDAP support. Either in form of detailed instructions and guidance in the documentation or in form of automated migration scripts.

Upstream support for moving contents of a domain from one backend to another is non-existent. This also applies when moving the LDAP backend driver from main configuration to domain specific configuration.

The root issue here is that when moving the LDAP backend from main configuration file to a domain specific configuration file Keystone will enable mapping of IDs.

Subsequently all existing assignments and resource ownerships are no longer valid after the move and must be migrated.

[James Page (james-page)]

See:

  https://review.openstack.org/#/q/topic:bug/1645803

for current reviews related to this feature; I also have a new charm (keystone-ldap) in progress

  https://github.com/openstack-charmers/charm-keystone-ldap

which implements the configuration options for the existing keystone charm, but as a domain specific backend driver.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/424059
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=795ebdeb19890923e40a7bc0aee9936508e53d3a
Submitter: Jenkins
Branch: master

commit 795ebdeb19890923e40a7bc0aee9936508e53d3a
Author: James Page <email address hidden>
Date: Mon Jan 23 11:06:06 2017 +0000

    Enable domain specific drivers

    Enable support for domain specific drivers, managed via
    configuration files (instead of directly using the API and
    database).

    Using multiple domains means that calls to users.list must
    be scoped to a specific domain; ensure that v3 calls to this
    method are appropriately scoped.

    Change-Id: I7ed84b7210597ab1633eba343a0c68741a5a8578
    Partial-Bug: 1645803

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/16.10
Review: https://review.openstack.org/426867

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/426867
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=b4b320c098253b0a1b0dcfd063a5354039f9cca8
Submitter: Jenkins
Branch: stable/16.10

commit b4b320c098253b0a1b0dcfd063a5354039f9cca8
Author: James Page <email address hidden>
Date: Mon Jan 23 11:06:06 2017 +0000

    Enable domain specific drivers

    Enable support for domain specific drivers, managed via
    configuration files (instead of directly using the API and
    database).

    Using multiple domains means that calls to users.list must
    be scoped to a specific domain; ensure that v3 calls to this
    method are appropriately scoped.

    NOTE: template file changes have NOT been backported.

    Partial-Bug: 1645803
    (cherry picked from commit 795ebdeb19890923e40a7bc0aee9936508e53d3a)
    Change-Id: I7ed84b7210597ab1633eba343a0c68741a5a8578

[Edward Hope-Morley (hopem)]

Pt 2 did not get autolinked so here it is - https://review.openstack.org/#/c/426171/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/426171
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=27b84f5b1325ee75340ea55ad0b43b44a3097ba9
Submitter: Jenkins
Branch: master

commit 27b84f5b1325ee75340ea55ad0b43b44a3097ba9
Author: James Page <email address hidden>
Date: Fri Jan 27 10:34:46 2017 +0000

    Add new subordinate relation for domain backends

    Support configuration of domains via suboridnate charms that
    implement the new 'keystone-domain-backend' relation type; these
    charms will create domain specific configuration files in
    /etc/keystone/domains, and will notify the keystone charm when
    configuration is complete, and the domain is ready for creation
    in the keystone database.

    Subordinate charms can also request a restart of keystone by
    setting or changing the value of the 'restart-nonce' key in the
    relation.

    Change-Id: Ia2b171e910d7f3a5e6e09ba5b18dddc0a734e57a
    Partial-Bug: 1645803