Comment 11 for bug 1508575

Revision history for this message
Edward Hope-Morley (hopem) wrote :

I've hit a very similar issue with the next charms whereby:

  * keystone has 3 units
  * keystone has a vip configured
  * keystone relations all receive service_host set to the vip
  * keystone db (i.e. endpoint) is configured to use non-vip

Looking at the code I think I can see why this is happening. The endpoint gets created by [1] which can be called from shared-db db_changed [2] hook or config_changed hook [3].

[1] https://github.com/openstack/charm-keystone/blob/stable/18.08/hooks/keystone_utils.py#L1105
[2] https://github.com/openstack/charm-keystone/blob/stable/18.08/hooks/keystone_hooks.py#L346
[3] https://github.com/openstack/charm-keystone/blob/stable/18.08/hooks/keystone_hooks.py#L246
[4] https://github.com/openstack/charm-keystone/blob/stable/18.08/charmhelpers/contrib/openstack/ip.py#L116

The problem is that if [2] executes prior to keystone being clustered then [4] never returns the vip hence the endpoint is set to be the local address of the unit. If I trigger a config change this does get fixed by [3] BUT if i don't it never gets resolved because [2] will never call [1] again once the db is initialised. I think we can easily fix this by adding a gratuitous call to [1] once the hacluster is complete.