Keystone does not provide relation data when clustered

[Liam Young]

When deploying keystone with a hacluster relation it does not provide relation data to its identity-service clients because it never thinks it is clustered.

The reason is that the charm uses goal state to see how many units it should have a relation with.
goal-state reports:

# goal-state
units:
  keystone/0:
    status: active
    since: 2018-11-05 13:43:12Z
  keystone/1:
    status: active
    since: 2018-11-05 13:49:29Z
  keystone/2:
    status: active
    since: 2018-11-05 13:48:28Z
relations:
  ha:
    keystone-hacluster:
      status: joined
      since: 2018-11-05 13:40:07Z
    keystone-hacluster/0:
      status: active
      since: 2018-11-05 13:50:48Z
    keystone-hacluster/1:
      status: active
      since: 2018-11-05 13:51:00Z
    keystone-hacluster/2:
      status: active
      since: 2018-11-05 13:52:53Z

So each keystone unit thinks it should have a relation with all the keystone-hacluster/N units. But keystone does not have a relation with all the units in the keystone-hacluster application because it is container scoped so it will only have a relation with its local unit.

root@juju-055968-20181105133223-1:/var/lib/juju/agents/unit-keystone-0/charm# relation-get -r ha:28 - keystone-hacluster/0
clustered: "yes"
egress-subnets: 10.5.0.21/32
ingress-address: 10.5.0.21
private-address: 10.5.0.21
root@juju-055968-20181105133223-1:/var/lib/juju/agents/unit-keystone-0/charm# relation-get -r ha:28 - keystone-hacluster/1
ERROR cannot read settings for unit "keystone-hacluster/1" in relation "keystone:ha keystone-hacluster:ha": unit "keystone-hacluster/1": settings not found

[Liam Young (gnuoy)]

https://bugs.launchpad.net/juju/+bug/1801765

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/615625

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/615625
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=32e4d822c101793a44f669ab1d12b8cb946e33fa
Submitter: Zuul
Branch: master

commit 32e4d822c101793a44f669ab1d12b8cb946e33fa
Author: Liam Young <email address hidden>
Date: Mon Nov 5 18:36:06 2018 +0000

    Only check for one unit for container scoped rels.

    When checking goal state, only look for one unit to be available
    when examining container scoped relations as a principle unit only
    ever has a relation with a single unit of a given subordinate
    application.

    Change-Id: I02f34358060c98c0702d3d7b58d52427c2a0445a
    Closes-Bug: #1801754