If multiple ldap servers are specified, no switch happens if first goes down

Bug #1812764 reported by Wouter van Bommel
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone LDAP integration
Expired
Medium
Unassigned
keystone (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Hi,

Just had the experience that in the charm 2 ldap servers where configured.
(juju config keystone-ldap ldap-server='ldaps://server1,ldaps://server2'

At the moment server1 went down, authentication was no longer possible. The only way to restore service, was by changing the order, so that server2 is referenced first.

This does not seem to be in line with the documentation that 'juju config keystone-ldap' gives, as there it is suggested that specifying multiple ldap servers should provide redundancy.

tags: added: canonical-bootstack
Revision history for this message
Xav Paice (xavpaice) wrote :

subscribed field-medium, this affects Bootstack customers.

Revision history for this message
James Page (james-page) wrote :

The charm configuration option is a direct pass through to the keystone ldap url configuration option which specifies:

"URL(s) for connecting to the LDAP server. Multiple LDAP URLs may be specified
 as a comma separated string. The first URL to successfully bind is used for the
 connection."

This is configured directly in the backend:

[ldap]
url = {{ options.ldap_server }}
user = {{ options.ldap_user }}

So I'm guessing that the fault here lies in whatever failover code exists in keystone and the underlying LDAP library to support failure detection and failover.

Changed in charm-keystone-ldap:
status: New → Invalid
Revision history for this message
James Page (james-page) wrote :

Please can you provide full details of which OpenStack release you are using on which Ubuntu release.

Thanks!

Changed in keystone (Ubuntu):
status: New → Incomplete
Revision history for this message
James Page (james-page) wrote :

Potentially related bug 1544821

Changed in charm-keystone-ldap:
status: Invalid → Incomplete
Revision history for this message
James Page (james-page) wrote :

We might be able to fix this in the charm so re-opening but it really depends on which openstack release is in play.

Revision history for this message
James Page (james-page) wrote :

For later releases ldappool is used for connection management, however the default connection_timeout configuration in keystone that gets passed to ldappool is -1 (disabled) so I'm not sure that failure detection will work.

Revision history for this message
James Page (james-page) wrote :

You could try passing

connection_timeout=5

via the charms ldap-config-flags option - that should end up in the correct sectional config.

Changed in charm-keystone-ldap:
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Keystone LDAP integration because there has been no activity for 60 days.]

Changed in charm-keystone-ldap:
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for keystone (Ubuntu) because there has been no activity for 60 days.]

Changed in keystone (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.