Duplicate entries for Region on login interface

Bug #1901046 reported by Diko Parvanov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard Charm
Triaged
Medium
Unassigned

Bug Description

Single region in openstack.

MODEL(openstack) jujumanage@svci0001:~$ openstack region list
+----------------+---------------+-------------+
| Region | Parent Region | Description |
+----------------+---------------+-------------+
| XXXXXXXXXXXXXX | None | |
+----------------+---------------+-------------+

On login interface a drop-down with 2 options, when selecting value 0 authentication fails, when selecting value 1 all works fine:

<select name="region" class="form-control" id="id_region">
  <option value="0">XXXXXXXXXXXXXX</option>
  <option value="1" selected="">XXXXXXXXXXXXXX</option>
</select>

Checking /etc/openstack-dashboard/local_settings.py there are 2 enties, for the same endpoint, one for http and one https:

AVAILABLE_REGIONS = [
('http://keystone.XXXXXXXXXXXXXX:5000/v2.0', 'XXXXXXXXXXXXXX'),
('https://keystoneXXXXXXXXXXXXXX:5000/v2.0', 'XXXXXXXXXXXXXX'),
]

Although template specifies this and there is a single region, the context contains 2 for some reason:

{% if regions|length > 1 -%}
AVAILABLE_REGIONS = [
{% for region in regions -%}
    ('{{ region.endpoint }}', '{{ region.title }}'),
{% endfor -%}
]
{% endif -%}

Keystone identity-service data relation below:

keystone/0:egress-subnets: MASKED
keystone/0:ingress-address: MASKED
keystone/0:private-address: MASKED
keystone/1:admin_domain_id: aa73475b635a437f9eac348b7074763a
keystone/1:api_version: "3"
keystone/1:auth_host: keystone-internal.XXXXXXXXXXXXXX
keystone/1:auth_port: "35357"
keystone/1:auth_protocol: https
keystone/1:egress-subnets: MASKED
keystone/1:ingress-address: MASKED
keystone/1:private-address: MASKED
keystone/1:region: zw-northeast-1
keystone/1:service_host: keystone.XXXXXXXXXXXXXX
keystone/1:service_port: "5000"
keystone/1:service_protocol: https
keystone/2:admin_domain_id: aa73475b635a437f9eac348b7074763a
keystone/2:api_version: "3"
keystone/2:auth_host: keystone-internal.XXXXXXXXXXXXXX
keystone/2:auth_port: "35357"
keystone/2:auth_protocol: http
keystone/2:egress-subnets: MASKED
keystone/2:ingress-address: MASKED
keystone/2:private-address: MASKED
keystone/2:region: zw-northeast-1
keystone/2:service_host: keystone.XXXXXXXXXXXXXX
keystone/2:service_port: "5000"
keystone/2:service_protocol: http

Charm iterates over the relation_ids('identity-service' in hooks/horizon_contexts.py:119 and doesn't take into account that key 'region' has the same name in both relations, one with http and another with https. Possibly a bug in keystone as well.

Diko Parvanov (dparv)
description: updated
description: updated
Diko Parvanov (dparv)
description: updated
description: updated
Revision history for this message
Diko Parvanov (dparv) wrote :

Workaround on this occasion was to run:

juju run --unit keystone/2 'relation-set -r identity-service:125 auth_protocol=https'
juju run --unit keystone/2 'relation-set -r identity-service:125 service_protocol=https'

where identity-service:125 is the relation id to openstack-dashboard.

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

Hi Diko, thanks for the bug report.

I suspect it's something to do with the cloud switching from http -> https when vault is unsealed, but for completeness, please could you also add to the bug report:

1. The ubuntu version
2. The OpenStack release (if not distro)
3. The charms release (or -next).
4. OR the bundle that was used to deploy the system.

Thanks.

Changed in charm-openstack-dashboard:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack openstack-dashboard charm because there has been no activity for 60 days.]

Changed in charm-openstack-dashboard:
status: Incomplete → Expired
Diko Parvanov (dparv)
description: updated
Changed in charm-openstack-dashboard:
status: Expired → 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.