Deploying keystone with LDAP read-only backend fails

[Kevin Metz]

When deploying Keystone with a LDAP read-only backend, the keystone charm can't create tenants, services and endpoints. Instead, administrator is required to deploy with SQL read-write backend and then switch to LDAP read-only. Given the typical production environments a read-only LDAP backend is not unusual.

[Nobuto Murata (nobuto)]

The charm has "ldap-readonly" flag. What is missing to support read-only LDAP deployment? Issues in config options or the order of deployment?
http://docs.openstack.org/developer/keystone/configuration.html#read-only-ldap

[Kevin Metz (pertinent)]

Tested deploying with the following bundle options

Set ldap-readyonly: false to establish a baseline for testing.

 charm: cs:xenial/keystone
    num_units: 1
    options:
      admin-password: openstack
      identity-backend: "ldap"
      ldap-server: "ldap://10.126.91.14"
      ldap-user: "cn=admin,dc=openstack,dc=org"
      ldap-password: "ldap"
      ldap-suffix: "dc=openstack,dc=org"
      ldap-readonly: "False"
      ldap-config-flags: "user_enabled_emulation=True"

Bundle still fails to deploy, and the following error is seen
unit-keystone-0: 2016-08-22 20:21:40 INFO worker.uniter.jujuc server.go:174 running hook tool "juju-log" ["-l" "INFO" "Retrying '_ensure_initial_admin' 1 more times (delay=9)"]
unit-keystone-0: 2016-08-22 20:21:40 INFO unit.keystone/0.juju-log server.go:270 shared-db:14: Retrying '_ensure_initial_admin' 1 more times (delay=9)
.........................

unit-keystone-0: 2016-08-22 20:21:49 INFO unit.keystone/0.shared-db-relation-changed logger.go:40 keystoneauth1.exceptions.http.InternalServerError: Internal Server Error (HTTP 500)

Keystone server does not show any errors in the log other than the juju error noted above in /var/log/juju logs

Unable to deploy bundle even when ldap is read/write

[James Page (james-page)]

I think the overall objective for the keystone charm should be to support LDAP backends well with Keystone v3; the existing LDAP support should probably never have been included in the charm as its awkward and fiddly to use.

For v3 - the service domain would continue to be SQL based (allowing the charm to create users as required for service accounts), with user domains being backed by LDAP/SQL or another identity provider.