Multiple regions in keystone create unexpected results in dashboard

[Robert van Leeuwen]

When there are multiple regions in the dashboard you can have all kinds of issues:
* The region you which you will get will be the lowest ID in the database, this is very inconvenient
* Feature disparity will break the dashboard (e.g. one region having security groups and another does not)
* When an API endpoint in any region is broken the dashboard can break (should be fixed with https://review.openstack.org/#/c/106101/ )

I've made a small feature for the dashboard that will filter Regions from the service catalog.
This means that you will only get to see one region on that dashboard.
(e.g. you can run multiple dashboards for different regions)

If this is acceptable for your environment it will fix all issues with multiple regions.
I'll try to get the patch attached to this bugreport ;)

[Mathieu Gagné (mgagne)]

Adding my own experience and use case:

You need a cloud with multi-regions. If ONE of the regions has volume service available but not the others, Horizon will think ALL regions has volume service available. It won't hide the volumes panel for regions without the service, throwing error messages all over the place.

[Mathieu Gagné (mgagne)]

My use case looks to be very similar to this one: #1368674

[Julie Pichon (jpichon)]

There was a patch to the django_openstack_auth project that looked to resolve this (feature disparity): bug 1212358, would that resolve your issues?

[Mathieu Gagné (mgagne)]

Yes, it fixed my issue. Thanks Julie.

However we are relying on Ubuntu Cloud Archive to provide packages and we are currently running from the Icehouse repository.

django-openstack-auth 1.1.7 which is available in the Juno repository requires:
- python-keystoneclient (>= 1:0.10.0)
- python-six (>= 1.7.0)

Those package versions are not available in the Icehouse repository and it causes problems to us. This means that for someone running Ubuntu, you have to upgrade to OpenStack Juno to get this "fix" which I find essential. :-/

[Julie Pichon (jpichon)]

That's unfortunate. My understanding is that, like the client libraries django_openstack_auth is meant to be backwards compatible and should be usable with older versions of the dashboard, which is why there is no stable branch to backport to. If an outright version upgrade is not possible, perhaps your distro's packagers would be open to backporting that single patch?

Because of the automatic requirements updates, it's difficult to assess if these increased dependencies numbers are actually necessary... :/

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Lyle (<email address hidden>) on branch: master
Review: https://review.openstack.org/114145
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Akihiro Motoki (amotoki)]

There is nothing to do as the upstream development. It is now a topic on how to manage django_openstack_auth version as operators or distribution packagers. Marking this as Invalid (as the upstream fix was done as a separate bug as mentioned in #3 and #4).