This is follow-up of I8438bedaf7cead452fc499e484d23690b48894d9 and
ensures the OPENSTACK_ENDPOINT_TYPE parameter is used when
OPENSTACK_KEYSTONE_ENDPOINT_TYPE is not set. This avoids backward-
incompatible change which affects deployments with endpoint type set
to non-default values.
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: I94d2d3e31fc0103773fb5d3ed2f5f792e8851f78
Users with domain admin role that are not cloud admins are
not able to get scoped context and create an application
credential with project_id, so this change forces the
scoped context in that particular case.
Closes-bug: #1827120
Change-Id: I076a97a6f943ab74a2db8bc5179a7db194009db4
The [1] changed the previous behavior of Horizon by
changing the hardcoded internal endpoint type to using
OPENSTACK_ENDPOINT_TYPE so it's no longer possible to use
internal endpoint type for Keystone but public for others.
This adds the OPENSTACK_KEYSTONE_ENDPOINT_TYPE config opt
to set the endpoint type for Keystone when grabbing it from
the service catalog.
[1] https://review.opendev.org/c/openstack/horizon/+/730781
Change-Id: I8438bedaf7cead452fc499e484d23690b48894d9
The original_ip parameter for the keystoneauth plugin
sets the Forwarded header sent to Keystone but right now
it just sends the IP address of Horizon instead of the client's
IP when Horizon is proxied and should use X-Forwarded-For.
Change-Id: Ic994b7f36d4c6459bbd00c810e3b454c6b1201a6
keystone does not distinguish public and admin endpoints since
Train [1], so there is no need to use a separate endpoint for
keystone admin operations. admin endpoint still can be configured
but there is no functional difference anymore from other endpoints.
We do not need to require admin endpoint and can use an endpoint
specified by OPENSTACK_ENDPOINT_TYPE for all API operations.
This commit reverts commit f9bab3fe195eb13635aa70cb910d94df98d66cf3
as we no longer need the workaround.
[1] https://review.opendev.org/c/openstack/keystone/+/664246
Closes-Bug: #1950659
Change-Id: I2660fd2df8081e1d2d9c84626037f94bd9d137a5
django.utils.translation.ugettext(), ugettext_lazy(), ugettext_noop(),
ungettext(), and ungettext_lazy() are deprecated in favor of the
functions that they’re aliases for: django.utils.translation.gettext(),
gettext_lazy(), gettext_noop(), ngettext(), and ngettext_lazy().
https://docs.djangoproject.com/en/4.0/releases/3.0/#id3
Change-Id: I77878f84e9d10cf6a136dada81eabf4e18676250
Keystone role names are case-insensistive and
Horizon should handle role names in a case-insensitive manner.
For example, when keystone bootstraps default roles,
it creates “admin”, “member”, and “reader”.
If another role, “Member” (note the upper case ‘M’) is created,
keystone will return a 409 Conflict since it considers the name “Member” equivalent to “member”.
Note that case is preserved in this event.
https://docs.openstack.org/keystone/latest/admin/case-insensitive.html#roles
Also whatever is written in defaults can be overridden in settings by the operator -
especially these days when actually the default should be 'member'
(one of the default roles created by Keystone during the bootstrap),
not _member_ which is there for legacy reasons I presume.
Change-Id: Ibfb80a47a8aaed8f33e4e1dcfb428e70c829f0dd
In python3, super() does not always require a class and self reference.
In other words, super() is enough for most cases.
This is much simpler and it is time to switch it to the newer style.
pylint provides a check for this.
Let's enable 'super-with-arguments' check.
NOTE: _prepare_mappings() method of FormRegion in
openstack_dashboard/test/integration_tests/regions/forms.py is refactored.
super() (without explicit class and self referece) does not work when
a subclass method calls a same method in a parent class multiple times.
It looks better to prepare a separate method to provide a common logic.
Change-Id: Id9512a14be9f20dbd5ebd63d446570c7b7c825ff
This pylint check 'no-else-return' might be debatable.
but as far as I checked it works in most cases.
Change-Id: Ie8574d4a529454c6e050fa62a7a17ea097d00240
The default url should be of type "OPENSTACK_ENDPOINT_TYPE"
parameter as specified in settings.
Closes-Bug: #1873353
Change-Id: I05ce933e5bd01bf59a52e7d49facce26efa693aa
Kyestone V2 support was removed in Train, so it's safe to do such cleanup.
* Functions which just return horizon settings are dropped and
the settings are referred directly now.
* The service catalog in the sample test data is updated to match
the format of the keystone API v3.
* Related to the above change of the sample service catalog,
openstack_dashboard.test.unit.api.test_keystone.ServiceAPITests is
updated to specify the region name explicitly because 'RegionTwo'
endpoint is no longer the second entry of the endpoint list in the
keystone API v3.
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: Ib60f360c96341fa5c618595f4a9bfdfe7ec5ae83
We don't support Python 2 anymore so we don't need this
compatibility library.
six.reraise usages are left as is until it'll be moved to some
base lib like oslo.utils to not re-implenent this method in
Horizon.
This patch also removes Python2-specific base test case methods
assertItemsEqual and assertNotRegexpMatches in flavor of new
Python 3 analogues.
Change-Id: I26a59176be9e9f213128e4945a58b9459334b626
In case of Keystone Multidomain setup, the project and users list
is empty when the domain context is changed. Horizon uses domain
scoped token for keystone api calls to get list of projects and users.
And domain scoped token cannot get information about projects and users
in other domains, the list is empty.
This patch modifies the use of domain scoped token only when domain
context is not modified.
The bug have 3 parts
1. Users are not listed on GUI in different domain
2. Projects are not listed on GUI in different domain
3. Gui hangs during creation of user/project using + option
This patch handles case 1 and 2.
Change-Id: Ibafe3e2eb3ee1ee5c9eb5d2a276a0edfa3e7c607
Partial-Bug: #1826114
Closes-Bug: #1830782
In Train cycle, we moved the definition of default values
to openstack_dashboard/defaults.py. The current code accesses
a dict member using []. It requires operators to define a dict
setting with a full member.
This commit allows to use dict-type settings with partial members.
A new function is introduced to retrieve a dict-type setting
considering default values defined in
{openstack_dashboard,horizon,openstack_auth}/defaults.py
Change-Id: I7ff0ad4bca698aef9c0eba370b0570200a14367a
Closes-Bug: #1843104
Keystone V2 API was deprecated in Stein release in Horizon and
removed from Keystone in Queens release.
Change-Id: I917e273d3174adf0874e516b3d635ccb8ba58a27
Cookie-based settings related to openstack_dashboard are located
under horizon directory,, but they are not related to "horizon".
This commit moves them to "openstack_dashboard" directory.
Part of blueprint ini-based-configuration
Change-Id: Id48ececdbe819a95485e9a91dc5a1a163a5568c3
In the early days of OpenStack, user and project ids were not
uuids, but auto-incremented integers.
Since those early days, many operators fought long battles
against the unrelenting OpenStack behemoth.
Only those heroic operators who emerged victorious from the
brutal upgrade battles can show the scars of those integer
user and project ids like badges of honour.
Closes-Bug: #1842004
Change-Id: I0c3e3465e8e7499c94d1a82b7295aeec13955e55
Currently horizon defines default values of settings in the logic
using getattr(settings, <setting name>, <default value>) and
it is not easy to handle the default values of available settings.
This commit starts the effort to define default settings explicitly.
This is a preparation for ini-based-configurations.
It covers settings in openstack_dashboard/api.
Part of blueprint ini-based-configuration
Change-Id: Id4c3287f0a572fd14ea93b54bcab8fabda39e583
It is possible to make Horizon reach the "Pure project admin doesn't
have a domain token" state in domain_lookup by having different policy
files in Keystone and in Horizon, at which point it results in an
unhelpful AttributeError later on, because domain_lookup returns None.
I'm proposing to make it return an empty dict instead, this way Horizon
doesn't crash, but we still get the warning in the logs.
Change-Id: I7a42e8defb2fb348cac8225fb1dcbf5e86c9e65c
pycodestyle 2.5.0 introduces E117 over-indented.
This commit fixes E117 errors.
pycodestyle 2.5.0 also drops pep8.py. As a result,
horizon/test/unit/hacking/test_checks.py starts to fail.
The equivalent elements are provided by pycodestyle.py,
so we can consume pycodestyle instead of pep8 module.
Change-Id: Ib103998f42ce7c901a10669b771a898783ca1a92
openstack_dashboard/dashboards/project/security_groups/forms.py:393:13: R1714: Consider merging these comparisons with "in" to "rule_menu in ('tcp', 'udp')" (consider-using-in)
openstack_dashboard/api/rest/json_encoder.py:61:15: R0124: Redundant comparison - o != o (comparison-with-itself)
openstack_dashboard/api/keystone.py:904:15: R1714: Consider merging these comparisons with "in" to 'default in (role.id, role.name)' (consider-using-in)
horizon/templatetags/truncate_filter.py:30:7: R1716: Simplify chained comparison between the operands (chained-comparison)
Change-Id: I6cf8602f88c4027ff12aaa4ea5a9f2069ae2e2a6
openstack_dashboard/context_processors.py:94:15: C0122: Comparison should be link['url'] != 'horizon:project:api_access:openrcv2' (misplaced-comparison-constant)
openstack_dashboard/settings.py:467:4: C0412: Imports from package horizon are not grouped (ungrouped-imports)
openstack_dashboard/enabled/_1370_project_vg_snapshots.py:9:0: C0301: Line too long (86/80) (line-too-long)
openstack_dashboard/enabled/_1360_project_volume_groups.py:9:0: C0301: Line too long (85/80) (line-too-long)
openstack_dashboard/usage/base.py:62:8: W0106: Expression "[instance_list.extend(u.server_usages) for u in self.usage_list]" is assigned to nothing (expression-not-assigned)
openstack_dashboard/dashboards/project/images/utils.py:43:12: W0106: Expression "[public_images.append(image) for image in images]" is assigned to nothing (expression-not-assigned)
openstack_dashboard/dashboards/project/images/utils.py:75:12: W0106: Expression "[community_images.append(image) for image in images]" is assigned to nothing (expression-not-assigned)
openstack_dashboard/api/glance.py:47:4: C0412: Imports from package glanceclient are not grouped (ungrouped-imports)
openstack_dashboard/api/cinder.py:60:4: C0412: Imports from package cinderclient are not grouped (ungrouped-imports)
openstack_auth/user.py:358:4: E0211: Method has no argument (no-method-argument)
openstack_auth/user.py:362:4: E0211: Method has no argument (no-method-argument)
openstack_dashboard/api/keystone.py:75:4: C0412: Imports from package keystoneclient are not grouped (ungrouped-imports)
horizon/loaders.py:43:16: W0706: The except handler raises immediately (try-except-raise)
horizon/themes.py:174:8: W0706: The except handler raises immediately (try-except-raise)
Change-Id: I40cf3ffbc4519657e11180d2e2fe7401387c5556
On identity-projects page:
Retrieve project list filtered by id which is not uuid format like '%',
there will throw an error message on top-right page.
And the same for identity-users page.
It is reasonable that return an empty list without error prompt.
Change-Id: I65aec86f4d894a9789eef6fc093ed95a95c46d9f
Closes-Bug: #1800600
The original code is monkey-patching keystoneclient object to add a
user_id attribute to it. This no longer works with more recent
versions of keystoneclient, as they wrap the client in a helper
class.
I'm not happy with this solution, it's likely to have side effects
and to break again. I'm putting it up for discussion for a better
solution.
Change-Id: Idb296d1b10fa02a0b4852e96fe8cb2bdd70380e0
Closes-bug: #1776678
This patch adds support for creating application credentials in
keystone[1]. Application credentials can be created by any user for
themselves. An application credential is created for the currently
selected project. A user may provide their own secret for the application
credential, or may allow keystone to generate a secret for them. After
the application credential is created, the secret is revealed once to
the user. At that point they may download a clouds.yaml or openrc file
that contains the application credential secret and will enable them to
use it to authenticate. The secret is not revealed again.
[1] https://docs.openstack.org/keystone/latest/user/application_credentials.html
bp application-credentials
Depends-On: https://review.openstack.org/557927
Depends-On: https://review.openstack.org/557932
Change-Id: Ida2e836cf81d2b96e0b66afed29a900c312223a4
This patch adds a utility to the keystone API manager to retrieve the
identity endpoint's version data and retrieve the current version as a
tuple. As part of this work, this patch converts the deprecated usage of
keystoneclient alone to using keystoneclient in combination with a
keystoneauth session.
Change-Id: I37031b67ab2681e81022a75afcb4f41c5700c47b
The current REST API tests have a lot of rooms to be improved like:
- mocking the whole module of the API wrapper
Change-Id: I799b0bce11bb06f6da64b8cc76f490f644fd457f
Partial-Bug: #1752917
This has been supported in the keystone API since version 3.6
Although not used in horizon (yet) some third party plugins may
require this.
Closes-Bug: #1729449
Change-Id: I961c1681b757134037ae767ac750afa36476d630
We still can show instance info on admin/instances page even if tenant
is deleted or we can't retrieve tenant's information.
Change-Id: Idb1a5ffbb4103cce5258657d559bf4fe784b98d6
Closes-Bug: #1712565
The current default settings of openstack_dashboard OPENSTACK_ENDPOINT_TYPE
has two default values 'publicURL' and 'internalURL' and this leads to
require both endpoints in deployments.
Having two default values for one setting is confusing. The comment in
local_settings.py says OPENSTACK_ENDPOINT_TYPE defaults to publicURL
and operators does not think internalURL is used.
I believe there is no negative side because if operators want to
deploy horizon out side of their OpenStack clouds they use publicURL
and if they want to deploy horizon behind load balancer or something
they would use internalURL as OPENSTACK_ENDPOINT_TYPE.
This also help the current devstack setup which only configures
public endpoint (interface) and Horizon does not work by default
for Identity dashboard.
Closes-Bug: #1686717
Change-Id: If5c7bbc5188f6df65661c41d777a9c7846fe9008
It is a variation of existing fix_auth_url_version() call which
returns as a second value a boolean flag indicating whether the
auth_url was fixed to point to /v3 endpoint. So we could display a
more clear message to deployers from Horizon, based on the value of
this flag. The legacy fix_auth_url_version() call is to be phased out
as soon as Horizon cease to depend on it. Also provide a release note
about removing the old function.
Change-Id: I6c6a35b1c460e22dadf39634fce1bdfa257b8c63
Depends-On: I3a04d838a707465c8c6e81e0e6e2fcf918b7b059
Since Horizon is going to be the first (or, one of the first)
OpenStack component using the new MongoDB driver, it won't be able to
retrieve traces made by other components using MongoDB driver (which
it should use because Ceilometer driver was too slow) for a
while. This means that Horizon itself is responsible for tracing the
rendering of its pages down to the layer where the flow of control
leaves Horizon domain. So, a lot of api wrappers in
openstack_dashboard.api are augmented with tracing decorator to
achieve this goal.
Co-Authored-By: Timur Sufiev <tsufiev@mirantis.com>
Implements-blueprint: openstack-profiler-at-developer-dashboard
Change-Id: Ib36692f0e9e68ed7fa0cd47919ba6581c9c8ab57
The description for the OPENSTACK_KEYSTONE_DEFAULT_DOMAIN django
variable claims it refers to the ID of the domain. However, the
authenticate method of django_openstack_auth explicitly uses the name
when it requests a token[1], and when multidomain support is enabled
the user is asked for the domain name, not ID. If the operator tries to
set this variable to the ID of any domain besides keystone's own
Default domain, login will fail with "Could not find domain: <domain
ID>" in the keystone logs. This patch forces horizon to use the
variable as a name instead of an ID and updates the comment, so that
everything using this variable is consistent with each other.
This wasn't caught before because the unit tests were only testing
against the default domain, so this patch also adds a second, enabled,
non-default mock domain to test with.
[1] http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/backend.py?h=2.4.1#n148
Change-Id: I4d16f831c9fc446859c9fb964b7609d5a76338fe