l-c job template moved the l-c jobs running on Focal
and currently fails on many constraints.
Let's keep running l-c job on bionic as it was before and we
can move it to Focal once issues are identified and fixed.
- Fixing the hacking tests which are behaving differently between
< 3.8.0 (until Ubuntu Bionic) and 3.8.2 (Ubuntu Focal).
Squashing below review also
- https://review.opendev.org/#/c/750786/
Co-Author: Lance Bragstad <lbragstad@gmail.com>
Change-Id: If733e9824d87d8c73797f753e4daf95489bed9c2
This makes it easier for operators to troubleshoot connection issues to
Memcached.
Related-Bug: 1332058
Change-Id: I6e67363822480314b93608bb1eae3514f1480f6d
In Ubuntu Bionic (18.04) mysql 5.7 version used to create
the user implicitly when using using the GRANT.
Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there
is no implicit user creation with GRANT. We need to
create the user first before using GRANT command.
This patch updates tools/test-setup.sh so that keystone supports
ubuntu focal.
Story: #2007865
Task: #40190
Change-Id: I86d10729cfc7c02f12df611b56f6e263969dfe4b
Closes-Bug: #1885825
The update registered limit updates the specified registered
limit. It will be wrong to describe it as "Update registered
limits". It should be singular. Same for updating a project
limit. This patch fixes the same.
Change-Id: Ie28f0661bd4402ebb8f9de37fff4c36b925c3b04
msgpack v1.0 changed its data format [1] and during a rolling upgrade, attempts
to unpack cached tokens with old data format with the new default raw=False
result in the following error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x87 in
position 3: invalid start byte
This passes raw=True to support backward-compat with the old format
until we are guaranteed to have msgpack >= 1.0 in the N-1 release of
a rolling upgrade.
Closes-Bug: #1891244
[1]
https://github.com/msgpack/msgpack-python/blob/v1.0.0/README.md#major-breaking-changes-in-msgpack-10
Change-Id: I6c61df6c097fef698c659c79402c4381ec7f3586
In the new version of PyMySql the error > 1000, will be
operational error [1], which is failing keystone migration
test cases [2] for backend mysql because we raise dberror
[3] which does not handle operational error.
PyMySQL hasn't been raised to 0.10.0 in the upper-constraints
yet, so this patch isn't going to be able to install it.
We can't raise the u-c since the current keystone jobs are
failing with it.
This patch overrides the test cases for backend SQL and skips
the same. This is so to make sure that failed test cases are
skipped because Once the upper-constraints are updated to
0.10.0 for PyMySql and merged, will revert the skip and
handle for 0.10.0.
[1]c3e5a63514
[2]https://da7bb9864083b9045f13-6176f3344d2541229da3be8329641f28.ssl.cf5.rackcdn.com/741837/2/check/cross-keystone-py36/d1a2e73/testr_results.html
[3]033e7aff87/keystone/tests/unit/test_sql_upgrade.py (L1867)
Related-Bug: #1890325
Change-Id: I207bb816affcb3e2725321de9a90a40c027a9f87
If LDAP returns a UUID as an octet string the LDAP driver will fail to
convert it to something meaningful. The error usually looks something
like:
ID attribute objectGUID not found in LDAP object
Microsoft AD's `objectGUID` parameter is stored and transmitted as an
octet string [0]. If you attempt to use the `objectGUID` to generate
user or group IDs, you'll get an HTTP 404 because keystone can't decode
it properly. This is unfortunate because `objectGUID` are a fixed
length, UUID format, and ideal for generating IDs in keystone. As
opposed to using the object's CN, which is variable length, and can
generate hashes that are larger than keystone's database table limit for
user IDs.
[0] https://docs.microsoft.com/en-us/windows/win32/ad/reading-an-objectampaposs-objectguid-and-creating-a-string-representation-of-the-guid
Change-Id: Id80b17bdff015e10340e636102576b7435bd564f
Closes-Bug: 1889936
We migrated to os-testr some time ago. There's no reason to keep this
around as a dependency.
Change-Id: Iedde135b9de03229c27ed57638d0c404169f43ab
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
GET /v3/auth/tokens?allow_expired=1 works fine with fernet tokens
returning the expired token data, whereas it returns exception
TokenNotFound for JWT. This patch fixes the same.
Change-Id: I03f6c58dce7d140d62055a97063aeb480498e5e6
Closes-Bug: #1886017
this option allows to override the
[security_compliance]disable_user_account_days_inactive setting from
config on per-user basis.
Co-Authored-By: Vishakha Agarwal <agarwalvishakha18@gmail.com>
Change-Id: Ida360e215426184195687bee2a800877af33af04
Closes-Bug: #1827431
When we create a project, using a project scoped token,
without add the domain_id or domain information in the
project creation parameters, this project will be
automatically created on the default domain.
Change-Id: Ib7a2d47c2204b0639f029c3079f4fa86ee78e3a9
In [1] a new parameter to domain API was added. This patch
updates the api-ref about the same.
[1] https://review.opendev.org/#/c/605235/
Change-Id: If288c3406e2fa840f698fec83d9643cfc0584f53
Closes-Bug: #1884062
We often have operators ask why cache logging isn't included in their
logs despite setting `keystone.conf [DEFAULT] debug=True`. This is
because cache logging requires additional configuration that isn't
obvious unless your familiar with oslo.cache and dogpile already.
This commit adds a section to the caching guide that shows people how to
update their configuration files when they need to debug caching issues.
Change-Id: I33d37366ea9caf320f3738db637dea7386ff6448
When you setup a user with a role assignment on a domain
and then a role assignment on a project "acting as a domain",
you can't actually remove them. The database throws you the
error "Multiple rows were found for one()" since it gets two
results for "actor_id" with the same "target_id".
This patch fixes this problem by filtering the database query
by "type" field to determine whether it is a user domain relation
or a user project and then removing the assignment.
Change-Id: Ife92a3c9e0982baafb4224882681c0855f573580
Closes-Bug: #1754677