auth_host fails for cross-model relations

Bug #1823745 reported by Cory Johns
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone Charm
Triaged
Medium
Unassigned

Bug Description

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.

Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :

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.

Changed in charm-keystone:
status: New → Triaged
importance: Undecided → Medium
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.