For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

Change-Id: I2d496fd5a76ca31a2ebbf275fdc348e8fc44394f

When we check the EC2 signature without the port part of the host value
received, we should properly split host:port. Keep in mind the splitting
should work for values like [fc00::]:123 too.

Change-Id: I1d90dfcea3568e2a9b22069daa428ea6a2a38bd6
Closes-Bug: #1988168

For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

Change-Id: I69d52a1d921e2c9376baef9ab54ba41aa9602b07

Move FIPS job to centos 9 and add new required nslookup_target variable.

Change-Id: Ifef262cfca4ecb8ad1222da3c43e5749f40c1f24

Change-Id: Iabc8cd0746871ea6ab81af9d3f0149644a489f3d
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Switch to alembic for real by integrating it into the 'db sync' command
flow. From a user-facing perspective, things should remain pretty much
the same as before, with the key difference being that version
information (i.e. what's shown by 'keystone-manage db_sync --check' or
'keystone-manage db_version') will now take the form of a hash rather
than an integer. There are a few differences for contributors however.
The changes are described in the included release note and
documentation.

Note that there are a couple of important design decisions here that are
worth examining:

- We drop the idea of the 'data_migration' branch entirely and the
  'keystone-manage db_sync --migrate' command is now a no-op. Neutron
  doesn't do data migrations like we do and yet they manage just fine.
  Dropping this gets us closer to neutron's behavior, which is a good
  thing for users.

- We haven't re-added the ability to specify a version when doing
  'db_sync'. Neutron has this, but the logic needed to get this working
  is complex and of questionable value. We've managed without the
  ability to sync to a version since Newton and can continue to do so
  until someone asks for it (and does the work).

- sqlalchemy-migrate is not removed entirely. Instead, upon doing a
  'db_sync' we will apply all sqlalchemy-migrate migrations up to the
  final '079_expand_update_local_id_limit' migration and dummy apply the
  initial alembic migration, after which we will switch over to alembic.
  In a future release we can remove the sqlalchemy-migrate migrations
  and rely entirely on alembic. Until then, keeping this allows fast
  forward upgrades to continue as a thing.

- Related to the above, we always apply *all* sqlalchemy-migrate
  migrations when calling 'db_sync', even if this command is called with
  e.g. '--expand' (meaning only apply the expand branch). This is
  because there is at most one "real" migration to apply, the Xena-era
  '079_expand_update_local_id_limit' migration, which is an expand-only
  migration. There is no risk to applying the empty "data_migration" and
  "contract" parts of this migration, and applying everything in one go
  results in *much* simpler logic.

Future changes will update documentation and add developer tooling for
(auto-)generating new migrations, a la 'neutron-db-manage revision'.

Change-Id: Ia376cb87f5159a4e79e2cfbab8442b6bcead708f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

We were inadvertently monkeypatching a variety of functions in
'keystone.common.sql.upgrades'. We should be configuring mocks for these
that we teardown at the end of the test. This has been an issue since we
first added these tests way back in change
I9f138fe0bcbf5ffbb98e6fcebd7d897329a301b7. Fix it now.

Change-Id: I185420e6d16276e7d184146f6a38b098abc00b25
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Suggested-by: Mike Bayer <mike_mp@zzzcomputing.com>

We can use the existing connection. No need to create a new one.

Change-Id: I2165710ee83dad12ddd795b665ecac6c8bd42a93
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Keystone's API policy rules are defaulting to system scope. Scope checks
are disabled by default in oslo.policy, but if you hit the API with a
token that doesn't match the scope, it generates a UserWarning, for
every policy check on that request. This is pretty annoying, so just
filter those warnings during our test runs.

Change-Id: I150b8fa19d4ec1582234caa4c25db905e6403590
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Keeps directories clean.

Change-Id: I8fcd9370a6adbfe8bbb2ce441a6f2efad45d089a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

The OAuth2.0 Access Token API is added, support to get an OAuth2.0
access token from the keystone identity server with application
credentials.

Change-Id: I4c54649a51534637be831450afc32d3ef8644ee5

Closed bug: #1916662

Change-Id: I3ae502580588af42ac5d5f9fc6718a639b443e98

For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

Change-Id: I64d941148743d2c7902f16f5e81888a647249c6f

The patch bumps min version of tox to 3.18.0 in order to
replace tox's whitelist_externals by allowlist_externals option:
https://github.com/tox-dev/tox/blob/master/docs/changelog.rst#v3180-2020-07-23

Change-Id: Iab6f7759de5cc0b5f52a6e5aa2069f5640d06e34

Change-Id: I92a8cfaef350bb61330d9ef02c0fd9e6f6c5854a

In Zed cycle, we have dropped the python 3.6/3.7[1] testing
and its support.

[1] https://governance.openstack.org/tc/reference/runtimes/zed.html

Change-Id: I817a4d1506fb7f15e72d37015ae0ba9547e2aa52

As discussed in TC PTG[1] and TC resolution[2], we are
dropping the lower-constraints.txt file and its testing.
We will keep lower bounds in the requirements.txt file but
with a note that these are not tested lower bounds and we
try our best to keep them updated.

[1] https://etherpad.opendev.org/p/tc-zed-ptg#L326
[2] https://governance.openstack.org/tc/resolutions/20220414-drop-lower-constraints.html#proposal

Change-Id: Id276f7efef3ef955b4c0b4b8d62f7c38cb535b33

The service_type config param is crucial to successfully use
application credentials with access rules.

Closes-Bug: #1950464
Change-Id: I98d1cfcbd229f2939d900861f453efa996466c32

Training-labs had been officially retired as no maintainer.
The information of training-labs has been deleting in the openstack
documentatioan. It is not appropriate to continue the presentation in
note form here.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.html
[2] https://opendev.org/openstack/training-labs/commit/e78d74f10558ab3e6a9a6fd7d45e617c15e9c3d8

Change-Id: I0ac3d05389041ac58fe2347171541ffaaf151fdf

Incorrectly said registered limit as opposed to just limit

Change-Id: I50856cd3488e2d13a6c35d097515b87f104690e1

Change-Id: I7a4d708c33049896ead745b61bd06477393b0392

Change-Id: I8e16fe1a002295753ab03cb8da74c0d43785f6d7

Some errors were logged without a traceback because they were
logged as a warning instead.

Change-Id: I68595e4e2c37279585f0434a173596e43e047004
Related-Bug: #1965316

Change-Id: I36f5eb44faf4c0e2ea7d68e8736e8fd34fdd5504

Add file to the reno documentation build to show release notes for
stable/yoga.

Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/yoga.

Sem-Ver: feature
Change-Id: I24bff76e6d727260446c6f8ff9709f409e2fae78

Currently rpm based distributions all use python3-devel.
Tested this with centos7 rhel7 rhel8 fedora35.

Change-Id: I9a8e6285edbb3799cf552acf479598b3b6c63b99