Cross model relation not completed for Keystone

[Alexandros Soumplis]

I am trying to make a cross model relation (Juju 2.5.0) between working keystone in a model and other openstack components (ex. nova-cloud-controller) in another model (same controller). The relations does not complete.

nova-cloud-controller/2* waiting idle 31/lxd/2 172.16.1.185 8774/tcp,8775/tcp,8778/tcp Incomplete relations: identity
nova-cloud-controller/7 waiting idle 37/lxd/2 172.16.1.209 8774/tcp,8775/tcp,8778/tcp Incomplete relations: identity
nova-cloud-controller/8 waiting idle 38/lxd/2 172.16.1.210 8774/tcp,8775/tcp,8778/tcp Incomplete relations: identity

The juju log displays:
4f6fdac1-0db2-448a-8a72-6d35727586b8: unit-nova-cloud-controller-7 2019-01-30 10:41:05 INFO unit.nova-cloud-controller/7.juju-log server.go:284 identity relation's interface, identity-service, is related awaiting the following data from the relationship: service_port, service_host, auth_host, auth_port, admin_tenant_name, admin_user, admin_password.

The debug-hook when adding the relation shows:
root@juju-7586b8-37-lxd-2:/var/lib/juju/agents/unit-nova-cloud-controller-7/charm# ./hooks/identity-service-relation-joined
ERROR no unit id specified
ERROR no unit id specified
lxc
lxc
lxc

[Ian Booth (wallyworld)]

Given the errors logged about missing unit id during hook execution, this appears to be an issue with the charm(s). For charms to play nicely with CMR, they need to adhere to certain practices, like using network-get rather than unit-get to ask Juju for address info etc. Charms also need to not assume they know the name of the remote units, as these are obfuscated across a cross model relation. The first thing to check is the structure of the charm themselves. There was recently a similar issue with one of the openstack charms which required the charm to be updated.

[covertgeek (derek-rushing)]

I'm using cs:nova-cloud-controller-320 and cs:keystone-291. The relation ID errors I'm receiving are the same as described above. This is blocking/preventing the openstack deployment in this case.

Here's a pastebin of my bundle.yaml.
https://pastebin.com/0SJywvFU

[covertgeek (derek-rushing)]

Here's a bundle.yaml with all the current versions being used. It's hopefully more helpful than the one referenced above.

https://pastebin.com/m6AVkwpW

[covertgeek (derek-rushing)]

Updating to reflect that this has also affected openstack-dashboard <--> keystone. I removed keystone and nova-cloud-controller from a HA setup and left the rest the same.

openstack-dashboard now reports "ERROR no relation id specified"

The relations is showing in the status.
"keystone:identity-service openstack-dashboard:identity-service keystone regular"

[James Page (james-page)]

Ignore the "ERROR no relation id specified" messages - these are a bit of a red herring in terms of cause for this problem.

I've endeavoured to reproduce this issue with keystone+percona-cluster in one model, and neutron+nova+glance+dashboard+percona-cluster in a second one - the relation appears to be working for me, with all services ready and active and all catalog entries created by the keystone charm.

I also reviewed the data on the keystone identity-service interface - none of it relies on unit names for completeness so it should be fine and its all network space aware so again this should be ok.

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for OpenStack nova-cloud-controller charm because there has been no activity for 60 days.]