auth_host fails for cross-model relations

[Cory Johns]

When using cross-model relations, auth_host sends the internal network address even when the public address is required.

To address this, charmhelpers.contrib.openstack.ip.resolve_address (https://github.com/juju/charm-helpers/blob/master/charmhelpers/contrib/openstack/ip.py#L117) needs to accept a relation_id param and switch to using network_get (https://github.com/juju/charm-helpers/blob/master/charmhelpers/core/hookenv.py#L1249) over the deprecated network_get_primary_address. Then, add_service_to_keystone (https://github.com/openstack/charm-keystone/blob/master/hooks/keystone_utils.py#L1536) needs to send the relation_id to resolve_address.

I'm a little uncertain if there are any backwards compatibility concerns from just switching resolve_address over to network_get unconditionally, so to be safe it might make sense to have add_service_to_keystone inspect the hook context to get the relation ID if not given explicitly so that resolve_address can continue to use the deprecated network_get_primary_address if no relation ID is given.

[Alex Kavanagh (ajkavanagh)]

TRIAGE: This is technically a wishlist item, as cross-model relations are not explicitly supported for the OpenStack charms, but I've set it to medium as keystone might be a good charm to actually provide a cross-model relation on as it's key (!) to providing authn/authz in clouds.