88fb018840
DEFAULT_SERVICE_REGIONS is cumbersome when you have more than one keystone endpoint and all you want to do is set a global default service region. This adds '*' as an optional fallback key to mean global default. If an endpoint matches it will take precedence over the '*' value. This also fixes the precedence order for DEFAULT_SERVICE_REGIONS so that a user controlled cookie is used instead when that cookie is valid for the given catalog. This changes the way the setting works, but retains the intended result the setting was originally intended for. Change-Id: Ieefbd642d853fcfcf22a17d9edcc7daae72790a4 blueprint: global-default-service-region Closes-Bug: #1772345 Related-Bugs: #1359774 #1703390
17 lines
789 B
YAML
17 lines
789 B
YAML
---
|
|
features:
|
|
- |
|
|
DEFAULT_SERVICE_REGIONS can now take '*' as a key which serves either as a
|
|
fallback service region, or the default region if no other keys are set.
|
|
upgrade:
|
|
- |
|
|
[:bug:`1772345`]
|
|
``DEFAULT_SERVICE_REGIONS`` no longer overrides the cookie value from
|
|
``services_region``. This fixes the UX where a user controlled value
|
|
keeps being overridden by a setting and changes ``DEFAULT_SERVICE_REGIONS``
|
|
to act as a default (as the name implies) per endpoint if the cookie is not
|
|
set rather than an override. The cookie will still be overridden when
|
|
it is for a region not present in the user's current catalog, so this will
|
|
still handle the original multi-keystone case that requried the
|
|
introduction of ``DEFAULT_SERVICE_REGIONS``.
|