Openstack-dashboard multi region bug?

juju
1

Greetings charmhub!

I’m running an experiment where I’m trying to make use of two openstack regions (edge computing scenario) one in Virginia (VA) and on in North Carolina (NC).

I’m finding the log in to the dashboard is failing because of this error.

[Sat Apr 17 21:07:41.454116 2021] [wsgi:error] [pid 407438:tid 140106969708288] [remote 192.168.125.140:49950] The OPENSTACK_KEYSTONE_URL setting points to a v2.0 Keystone endpoint, but v3 is specified as the API version to use by Horizon. Using v3 endpoint for authentication.
[Sat Apr 17 21:07:41.535440 2021] [wsgi:error] [pid 407438:tid 140106969708288] [remote 192.168.125.140:49950] Login failed for user "admin" using domain "admin_domain", remote address 192.168.125.140.

I looked at the settings in /etc/openstack-dashboard/local_settings.py on all of the dashboard hosts and I see that the charm has built the config like this:

# For multiple regions uncomment this configuration, and add (endpoint, title).
#AVAILABLE_REGIONS = [
#    ('http://cluster1.example.com:5000/v2.0', 'cluster1'),
#    ('http://cluster2.example.com:5000/v2.0', 'cluster2'),
#]
AVAILABLE_REGIONS = [
('https://keystone.lab.devzero.home:5000/v2.0', 'NC'),
('https://keystone.lab.devzero.home:5000/v2.0', 'VA'),
]
OPENSTACK_HOST = "keystone.lab.devzero.home"
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "member"
OPENSTACK_KEYSTONE_URL = "https://%s:5000/v3" % OPENSTACK_HOST
OPENSTACK_API_VERSIONS = { "identity": 3, }
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = "266dd97fa7b14afeaa0335197fbd4fdf"

If I manually change the AVAILABLE_REGIONS lines to be (https://keystone.lab.devzero.home:5000/v3’, ‘NC’) and (https://keystone.lab.devzero.home:5000/v3’, ‘VA’) respectively - the log in is successful, but the configuration gets reverted after about 12 hours when… jujud refreshes???

I’m wondering if there’s a setting I’ve missed or should I log a bug?

2

Disclaimer: I’m not a programmer I couldn’t python myself out of a wet paper bag if I tried, but here’s what I’ve got so far.

It appears that horizon_contexts.py “update(s) the service endpoint and title for each available region in order to support multi-region deployments” with a hardcoded v2.0 Keystone endpoint ( lines 175 -> 196 )

As a test I’ve cloned the openstack-dashboard repo to a local directory and made these local comments and changes:

if region is not None:
    if config("use-internal-endpoints") and internal_host:
        endpoint = ("%(internal_protocol)s://%(internal_host)s"
                    #":%(internal_port)s/v2.0") % local_ctxt
                    ":%(internal_port)s/v3") % local_ctxt
    else:
        endpoint = ("%(service_protocol)s://%(service_host)s"
                    #":%(service_port)s/v2.0") % local_ctxt
                    ":%(service_port)s/v3") % local_ctxt

I then deployed the local charm like this:

juju deploy ./charm-openstack-dashboard my-horizon --series focal --to lxd:0
juju deploy cs:mysql-router my-horizon-dashboard-mysql-router
juju relate my-horizon my-horizon-dashboard-mysql-router
juju relate my-horizon-dashboard-mysql-router:db-router mysql-innodb-cluster:db-router
juju relate my-horizon:identity-service keystone:identity-service
juju relate my-horizon:certificates vault:certificates

I ssh’d to the newly built unit and confirmed that /etc/openstack-dashboard/local_settings.py has been templated with the following:

# For multiple regions uncomment this configuration, and add (endpoint, title).
#AVAILABLE_REGIONS = [
#    ('http://cluster1.example.com:5000/v2.0', 'cluster1'),
#    ('http://cluster2.example.com:5000/v2.0', 'cluster2'),
#]
AVAILABLE_REGIONS = [
('https://keystone.lab.devzero.home:5000/v3', 'NC'),
('https://keystone.lab.devzero.home:5000/v3', 'VA'),
]
OPENSTACK_HOST = "keystone.lab.devzero.home"
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "member"
OPENSTACK_KEYSTONE_URL = "https://%s:5000/v3" % OPENSTACK_HOST
OPENSTACK_API_VERSIONS = { "identity": 3, }
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = "0fe5133fa2bb4ff38d857a9f3e1b5e28"

Opinions from actual programmers/charmers … @openstack-charmers ?

3

It definitely looks like you should raise a bug (although I happily will if you’d rather, considering how much effort you’ve put in already!). The fix looks generally good, except that it probably does need to support both v2 and v3 endpoints, depending on the OpenStack version.

4

Thanks @chris.macnaughton
Not having a programming back ground I thought I’d discuss before creating a bug unnecessarily

I’ve logged Bug #1925669