Ed, the problem is that when configuring LDAP, the value itself might be a comma delimited value (see LDAP configuration reference here --> http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html). Unfortunately, the standard charm parsing here is taking a string and using the comma as a delimter, whereas a comma should not be a valid delimiter.
As you can see here (http://bazaar.launchpad.net/~openstack-charmers/charms/precise/keystone/trunk/view/head:/config.yaml#L124) the config option clearly states that the config flags should be a comma separated list of key/value pairs and if you further check the code you'll find that it uses the standard config flag parsing logic here - which means there's no good way to specify a key such as the user_tree_dn or any of the advanced filtering & queries that can be done with an LDAP server.
I think we should consider making this optionally in the format of a yaml associative array which would allow a bit more flexibility in specifying the complex options like so.
Ed, the problem is that when configuring LDAP, the value itself might be a comma delimited value (see LDAP configuration reference here --> http:// docs.openstack. org/admin- guide-cloud/ content/ configuring- keystone- for-ldap- backend. html). Unfortunately, the standard charm parsing here is taking a string and using the comma as a delimter, whereas a comma should not be a valid delimiter.
As you can see here (http:// bazaar. launchpad. net/~openstack- charmers/ charms/ precise/ keystone/ trunk/view/ head:/config. yaml#L124) the config option clearly states that the config flags should be a comma separated list of key/value pairs and if you further check the code you'll find that it uses the standard config flag parsing logic here - which means there's no good way to specify a key such as the user_tree_dn or any of the advanced filtering & queries that can be done with an LDAP server.
I think we should consider making this optionally in the format of a yaml associative array which would allow a bit more flexibility in specifying the complex options like so.