| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lower-constraints is not a requirement of the OpenStack Python PTI
[0] and there currently is a discussion on the mailing list [1]
about dropping the test, with the oslo team already having done
so [2].
The new dependency resolver in pip fails due to incompatible
dependency versions in our lower-constraints file, meaning that
we were never providing any real guarantees with it.
To unblock the CI, I am disabling lower-constraints job for now,
with the option to reenable it in case we fix the constraints,
and based on the outcome of the mailing list discussions and
consensus.
[0]. https://governance.openstack.org/tc/reference/pti/python.html
[1]. http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
[2]. http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019659.html
Change-Id: I47e747058891596e7717848a0b0bc10f0a235b2f
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit just addresses minor comments in the release note wording
for the original review:
https://review.opendev.org/#/c/731087/10/releasenotes/notes/bug-1878938-70ee2af6fdf66004.yaml
Change-Id: I00aa074393b8498efde35d843fb0d05a209f2b5c
|
| |\ \ \ \
| |/ / /
| | | /
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch ensures to delete the system role assignments from
all the assignment tables in keystone after deleting the role
user has over the system.
This also make sure of deleting stale role assignments before
deleting role for the deployments that are already in this state.
Closes-Bug: #1878938
Change-Id: I4df19c45c870ff3fb78578ca1fb7dd0d35da3c82
|
| |\ \ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add support to the keystone devstack plugin for setting enforce_scope in
the keystone config and setting up tempest to test it.
It may be better to move this to tempest proper at some point.
See also: https://review.opendev.org/686073 https://review.opendev.org/698397
Change-Id: I1b71135547b7ce03afb5b44fbbab3f52d213a2ae
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Keystone's paging implementation contains a memory leak. The issue is
noticeable if you integrate keystone with an LDAP server that supports
paging and set `keystone.conf [ldap] page_size` to a low integer
(e.g., 5).
Keystone's LDAP backend uses `python-ldap` to interact with LDAP
servers. For paged requests, it uses `search_ext()`, which is an
asynchronous API [0]. The server responds with a message ID, which the
client uses to retrieve all data for the request. In keystone's case,
the `search_ext()` method is invoked with a page control that tells
the server to deliver responses in increments according to the page
size configured with `keystone.conf [ldap] page_size`. So long as the
client has the original connection used to fetch the message ID, it
can request the rest of the information associated to the request.
Keystone's paging implementation loops continuously for paged
requests. It takes the message ID it gets from `search_ext()` and
calls `result3()`, asking the server for the data associated with that
specific message. Keystone continues to do this until the server sends
an indicator that it has no more data relevant to the query (via a
cookie). The `search_ext()` and `result3()` methods must use the same
LDAP connection.
Given the above information, keystone uses context managers to provide
connections. This is relevant when deploying connection pools, where
certain connections are re-used from a pool. Keystone relies on Python
context managers to handle connections, which is pretty typical
use-case for context managers. Connection managers allow us to do the
following (assuming pseudocode):
with self.get_connection as conn:
response = conn.search_s()
return format(response)
The above snippet assumes the `get_connection` method provides a
connection object and a callable that implements `search_s`. Upon
exiting the `with` statement, the connection is disconnected, or put
back into the pool, or whatever the implementation of the context
manager decides to do. Most connections in the LDAP backend are
handled in this fashion.
Unfortunately, the LDAP driver is somewhat oblivious to paging, it's
control implementation, or the fact that it uses an asynchronous API.
Instead, the driver leaves it up to the handler objects it uses for
connections to determine if the request should be controlled via
paging. This is an anti-pattern since the backend establishes the
connection for the request but doesn't ensure that connection is
safely handled for asynchronous APIs.
This forces the `search_ext()` and `result3()` implementations in the
PooledLDAPHandler to know how to handle connections and context
managers, since it needs to ensure the same connection is used for
paged requests. The current code tried to clean up the context
manager responsible for connections after the results are collected
from the server using the message ID. I believe it does this because
it needs to get a new connection for each message in the paged
results, even though it already operates from within a connection
established via a context manager and the PooledLDAPHandler almost
always returns the same connection object from the pool. The code
tries to use a weak reference to create a callback that tears down the
context manager when nothing else references it. At a high-level, the
idea is similar to the following pseudocode:
with self.get_connection as conn:
while True:
ldap_data = []
context_manager = self.get_connection()
connection = context_manager.__enter__()
message_id = connection.search_ext()
results = connection.result3(message_id)
ldap_data.append(results)
context_manager.__exit__()
I wasn't able to see the callback get invoked or work as described in
comments, resulting in memory bloat, especially with low page sizes
which results in more requests. A weak reference invokes the callback
when the weak reference is called, but there are no other references
to the original object [1]. In our case, I don't think we invoke that
path because we don't actually do anything with the weak reference. We
assume it's going to run the callback when the object is garbage
collected.
This commit attempts to address this issue by using the concept of a
finalizer [2], which was designed for similar cases. It also attempts
to hide the cleanup implementation in the AsynchronousMessage object,
so that callers don't have to worry about making sure they invoke the
finalizer.
An alternative approach would be to push more of the paging logic and
implementation up into the LDAP driver. This would make it easier to
put the entire asynchronous API flow for paging into a `with`
statement and relying on the normal behavior of context managers to
clean up accordingly. This approach would remove the manual cleanup
invocation, regardless of using weak references or finalizer objects.
However, this approach would likely require a non-trivial amount of
design work to refactor the entire LDAP backend. The LDAP backend has
other issues that would complicate the re-design process:
- Handlers and connection are generalized to mean the same thing
- Method names don't follow a convention
- Domain-specific language from python-ldap bleeds into keystone's
implementation (e.g., get_all, _ldap_get_all, add_member) at
different points in the backend (e.g., UserApi (BaseLdap), GroupApi
(BaseLdap), KeystoneLDAPHandler, PooledLDAPHandler,
PythonLDAPHandler)
- Backend contains dead code from when keystone supported writeable
LDAP backends
- Responsibility for connections and connection handling is spread
across objects (BaseLdap, LDAPHandler)
- Handlers will invoke methods differently based on configuration at
runtime, which is a sign that the relationship between the driver,
handlers, and connection objects isn't truely polymorphic
While keeping the logic for properly handling context managers and
connections in the Handlers might not be ideal, it is a relatively
minimal fix in comparison to a re-design or backend refactor. These
issues can be considered during a refactor of the LDAP backend if or
when the community decides to re-design the LDAP backend.
[0] https://www.python-ldap.org/en/python-ldap-3.3.0/reference/ldap.html#ldap.LDAPObject.search_ext
[1] https://docs.python.org/3/library/weakref.html#weakref.ref
[2] https://docs.python.org/3/library/weakref.html#finalizer-objects
Closes-Bug: 1896125
Change-Id: Ia45a45ff852d0d4e3a713dae07a46d4ff8d370f3
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html
Change-Id: Ie519d4d4c95e6450435f9026a45e2e1e7b9855d4
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The newest vine release (5.0.0) is incompatible with the version of amqp
used on stable branches and results in test errors[1]:
"AttributeError: False does not have the attribute 'info'"
Ensure the lower-constraints tox environment uses the same version of
vine as defined in upper-constraints.txt.
[1] https://zuul.opendev.org/t/openstack/build/78dfcdd4272241459fb904aa70600e5b
Change-Id: I4b9b11b89e9f4120ae4b7fb8e213628dd9e8121c
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When run in parallel, there is a race condition in which the cleanup of
the generated sample config file may happen while another unit test is
trying to read from it, causing the test to fail[1]. Since both
test_config_default and test_profiler_config_default are simply
asserting properties of the default config file and not testing
different corner cases, it's simplest to combine the two tests and not
worry about when and how the sample file is cleaned up.
[1] https://zuul.opendev.org/t/openstack/build/d870ff2db4b74c21a66b756f4377a0c4/artifacts
Change-Id: If5de3b3499ea73c601e8793cba4fef3441d72f5d
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per victoria cycle testing runtime and community goal[1]
we need to migrate upstream CI/CD to Ubuntu Focal(20.04).
Fixing:
- bug#1886298
Bump the lower constraints for required deps which added python3.8 support
in their later version.
Story: #2007865
Task: #40190
Closes-Bug: #1886298
[1] https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal
Change-Id: I5712f29beee2bd7d8ba857c0ce2cd2287646d6b0
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This Patch fixes the 'middleware' spelling.
Change-Id: I6659ca49db86e5c20ecf80e4c4fff93328616eb6
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| |\ \ \ \ \
| | |/ / /
| |/| | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This patch fixes spelling "project" in test_sql_upgrade.py file.
Change-Id: I8b1a8dbea5fb17707e59fae8605cc615f1b51f2c
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| |\ \ \ \ \ \ |
|
| | | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Although, Keystone doesn't use the pysaml2 signature on [0]
Would be nice to bump the pysaml2 version for, at least, 5.0.0[1] in
order to have the the CVE fix included[2].
[0]https://opendev.org/openstack/keystone/src/branch/master/keystone/federation/idp.py#L440-L521
[1] https://github.com/IdentityPython/pysaml2/releases/tag/v5.0.0
[2] https://github.com/advisories/GHSA-qf7v-8hj3-4xw7
Change-Id: I1d3776f7f1feb6485feecb140703f23027ca3a6f
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |\ \ \ \ \ \ \ |
|
| | | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This patch closes the review comments of [1].
[1]https://review.opendev.org/#/c/745752/
Change-Id: I06b02b2ebfed35d4e82c5fc35ce8eb0bb20b2fc5
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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]https://github.com/PyMySQL/PyMySQL/commit/c3e5a63514c57d1f4c9d5e7bf4b7e10b0608b0e1
[2]https://da7bb9864083b9045f13-6176f3344d2541229da3be8329641f28.ssl.cf5.rackcdn.com/741837/2/check/cross-keystone-py36/d1a2e73/testr_results.html
[3]https://github.com/openstack/keystone/blob/033e7aff870f2ccd4dec607e9c47efff630ece29/keystone/tests/unit/test_sql_upgrade.py#L1867
Related-Bug: #1890325
Change-Id: I207bb816affcb3e2725321de9a90a40c027a9f87
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
According to the [1], list endpoints filter also have
``region_id`` parameter which is missing from api-ref.
This patch updates the same in api-ref.
[1]https://github.com/openstack/keystone/blob/master/keystone/api/endpoints.py#L78
Change-Id: I3982c98506f945b47c056ed1c9e5eee673a3662a
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The __future__ module [1] was used in this context to ensure compatibility
between python 2 and python 3.
We previously dropped the support of python 2.7 [2] and now we only support
python 3 so we don't need to continue to use this module and the imports
listed below.
Imports commonly used and their related PEPs:
- `division` is related to PEP 238 [3]
- `print_function` is related to PEP 3105 [4]
- `unicode_literals` is related to PEP 3112 [5]
- `with_statement` is related to PEP 343 [6]
- `absolute_import` is related to PEP 328 [7]
[1] https://docs.python.org/3/library/__future__.html
[2] https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html
[3] https://www.python.org/dev/peps/pep-0238
[4] https://www.python.org/dev/peps/pep-3105
[5] https://www.python.org/dev/peps/pep-3112
[6] https://www.python.org/dev/peps/pep-0343
[7] https://www.python.org/dev/peps/pep-0328
Change-Id: I2f9d2114b2c5eb66f241646f1896ea17a160e3f3
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
self.assertTrue(len(user['federated']), 1) should be
self.assertEqual(len(user['federated']), 1).
Change-Id: If6bdfb074cb68271e69f8436111149d3aa312e6d
|
| |\ \ \ \ \ \ \ |
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |\ \ \ \ \ \ \ \ |
|
| | | |_|_|/ / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It implements the same behavior of the old one.
It is worth noting that the existing job the MULTI_KEYSTONE does not
produce any effect because this change hasn't been merged yet:
- https://review.opendev.org/399472
and when that merges, the following devstack-gate changes should be
applied directly to this new job definition instead:
- https://review.opendev.org/394895
Both changes are out of scope for this porting.
Change-Id: I5d5d31c8d89b0d2812a5e9be18a81611041e6da8
|
| | |_|_|/ / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
keystone does not have any lower constraint for PyMySQL so the
latest version 0.10.0 is picked by the job which is failing [1]
In OpenStack, PyMySQL upper constraint is .9.3 means that version
is tested not 0.10.0 [2] let's add PyMySQL lower constraint also
so that we test lower-constraint job with correct lower version.
[1]https://zuul.opendev.org/t/openstack/build/3077d96f4fff4b7985cb763d0635d471/log/job-output.txt#621
[2]https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L384
Change-Id: I3834b3b34641c006c70614d5331d292c41f8a346
Closes-Bug: #1888886
|
| |\ \ \ \ \ \ \ |
|
| | | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This adds support for the "regex" flag for both the "whitelist" and
"blacklist" conditional types. Before, only the "any_one_of" and
"not_any_of" conditionals supported this. Similar to the pre-existing
regex logic, the patterns are matched from the beginning of the string,
meaning you may need prefix them with ".*" if you do not care about the
first characters of the match.
Closes-Bug: #1880252
Change-Id: Ia51f47a58712c7230753f2cfa0c87b83a7339bf9
|
| |\ \ \ \ \ \ \ |
|
