In multi region environment Horizon logs into incorrect region.

[Dmitry Nikishov]

Environment: MOS 6.0

There are 2 DCs with multi-region configuration enabled: NORTH and SOUTH.

When authenticating in either Horizon (NORTH or SOUTH), the dashboard seems to use SOUTH DC, whereas it is expected to use respective region.

Also, after changing tenant, the dashboard seems to reset to SOUTH DC too.

[Dmitry Mescheryakov (dmitrymex)]

It is too late to try to fix this bug in 6.1 as hard code freeze is too close, hence assigning to 7.0.

[Timur Sufiev (tsufiev-x)]

Paul, please contact Justin Pomeroy regarding upstream bug 1359774 and find out what blocks his progress. Perhaps it would be better if we ourselves finish this upstream patch (provided Justin doesn't mind).

[Max Yatsenko (myatsenko)]

The following behaviour was reproduced:

We have two regions: RegionOne and RegionTwo.

When we log in to dashboard of RegionOne or RegionTwo
we have RegionOne as default region on both dashboards.
If you change a region and if you log out/log in during same session
these changes are stored. When you try to log in during new session
you get RegionOne again as default one.

[Timur Sufiev (tsufiev-x)]

I also did see what happened with Regions & Projects on 2 above labs. Here is what I found: current project and region are stored between logins. Switching the project doesn't reset the current region. The only thing I can confirm is that logging into different endpoint has an independent list of regions, which don't have to reflect the endpoint. It was a horrible misnaming to use 'AVAILABLE_REGIONS' name for the setting that actually contains different keystone endponts - which are orthogonal to keystone regions. Also please note that I didn't choose endpoint on login page, because we hadn't managed to fully reproduce the setup for which the bug was filed - due to insufficient instructions. Please provide us with more detailed steps on how to prepare these two endpoints, each with 2 different regions. Meanwhile I mark this one as Incomplete.

[Vitaly Sedelnik (vsedelnik)]

That looks like a valid issue for 6.0, 6.1 and 7.0. I am targetting it for maint updates and to 8.0.

[Dmitry Nikishov (nikishov-da)]

There are 2 DCs (E.g. regionA and regionB);

Each DC's Keystone has endpoints for it's home region configured, as well as endpoints for other region.

When user logs into Dashboard, physically located in regionB, he expects to use regionB endpoints (to access resources in said region). However, Dashboard uses endpoints for regionA anyway (probably because under the hood keystone endpoints are being filtered and sorted alphabetically).

This means that user has to switch to regionB all the time, no matter which region's VIP he has used to access the cloud.

TLDR:
What it should be:
User accesses VIP of region A ----> User must be directed to region A resources by default
User accesses VIP of region B ----> User must be directed to region B resources by default

How it is now:
User accesses VIP of region A ----> User is directed to resources of whatever region, which comes up first in service catalog.

[Timur Sufiev (tsufiev-x)]

As we agreed with Dmitry in private discussion, the desired behavior is for the User to be able to select the default service region when logging in. The upstream bug for this issue is bug 1359774, it has already all the code in gerrit, I'll facilitate it's merging.

[Timur Sufiev (tsufiev-x)]

It appears that I rushed a bit here with conclusions. As we further discussed with Dmitry, Justin's patch (https://review.openstack.org/#/c/224883/1/doc/source/topics/settings.rst) for above bug is not ideal. It introduces SERVICE_REGION_CHOICES setting which contains a list of predefined service regions (to be found in a Keystone backing a Horizon), so the User can choose between them. A list of regions will become outdated more quickly than a single DEFAULT_SERVICE_REGION setting chosen separately for each Keystone endpoint. Also, we don't yet know how this will align with Keystone Federations initiative. Lowering the bug to Medium (agreed with Dmitry) and continuing discussion in Justin's patch.

[Fuel Devops McRobotson (fuel-devops-robot)]

Fix proposed to branch: 8.0
Change author: Timur Sufiev <email address hidden>
Review: https://review.fuel-infra.org/12751

[Fuel Devops McRobotson (fuel-devops-robot)]

Fix proposed to branch: openstack-ci/fuel-8.0/liberty
Change author: Timur Sufiev <email address hidden>
Review: https://review.fuel-infra.org/12752

[Timur Sufiev (tsufiev-x)]

Upstream bug 1506825.

[Fuel Devops McRobotson (fuel-devops-robot)]

Fix proposed to branch: openstack-ci/fuel-8.0/liberty
Change author: Paul Karikh <email address hidden>
Review: https://review.fuel-infra.org/13488

[Fuel Devops McRobotson (fuel-devops-robot)]

Change abandoned by Timur Sufiev <email address hidden> on branch: 8.0
Review: https://review.fuel-infra.org/12751
Reason: Superseded with https://review.fuel-infra.org/#/c/13488/2

[Paul Karikh (pkarikh)]

Assigning to Max Yatsenko since he is working on setting up the env for this bug.

[Timur Sufiev (tsufiev-x)]

Won't Fix because the Keystone multi-region configuration desired by Customer was implemented using some tricky hacks, that are no way going to be supported in upstream. Keystone community encourages to use Federation to implement such use cases, but unfortunately the first stable version of working federation is coming no sooner than in 1 year from today.

[Fuel Devops McRobotson (fuel-devops-robot)]

Change abandoned by Timur Sufiev <email address hidden> on branch: openstack-ci/fuel-8.0/liberty
Review: https://review.fuel-infra.org/12752
Reason: Not going to work nicely with Keystone.

[Fuel Devops McRobotson (fuel-devops-robot)]

Change abandoned by Timur Sufiev <email address hidden> on branch: openstack-ci/fuel-8.0/liberty
Review: https://review.fuel-infra.org/13488
Reason: Won't work on Keystone side.