This reverts commit 6abf69e194c9dac13d26bca3e7ac1f710f9e26a0.

Keeping Python 3.10 in setup.cfg classifier. 

Reason for revert:

Needed-By: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/882175

TC has been discussing about re-adding the python 3.8
testing in current master 2023.2 release testing.

- https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.log.html#l-191
- https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033469.html

While governance changes are under review, TC agreed to add py3.8 testing
so that we do not see more project/lib dropping python 3.8 and make them
uninstalable on python 3.8

- https://meetings.opendev.org/meetings/tc/2023/tc.2023-05-02-18.00.log.html#l-17
- https://review.opendev.org/c/openstack/governance/+/882165

Also adding py3.8 testing back in job https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/882175

Change-Id: Ib5b901f245cb65bbd9deee6e030ddb96fc7b8015

Within 2023.2 python version 3.9 and 3.10 are the
supported python runtimes [1].
[1] https: //review.opendev.org/c/openstack/governance/+/872232

Change-Id: Ibabaaf286ca4ce942908086e490929900ccf7c95

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

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

Sem-Ver: feature
Change-Id: I8e979b65ca350f53b6eb795f5d2358c628268425

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

Change-Id: If528578c75c86ab560b19a53e32fca921c827878

Change-Id: I07d2126176d00acf361349fa6f8de6b34ae64a16

This repo is now testing only with Python 3, so let's make
a few cleanups:
- Remove python 2.7 stanza from setup.py

Change-Id: I82753bf268ebcc6fd701a56c64534a9cd3d5b4ae

This patch changes the ``log.setup()`` signature to allow a kwarg
that makes the eventlet logging fix conditional.

Some libraries that import oslo.log, replace the logging locking
handling with its own implementation. For example oslo.privsep
replaces the logging handler with its own one [1], that allows the
communication between the privileged daemon process and the service
importing the library. This local handler clashes with the
evenlet logging fix implemented in [2].

[1]https://github.com/openstack/oslo.privsep/blob/1020c6fbf54f93cad9fa36b97bcd9cf75549984a/oslo_privsep/daemon.py#L579
[2]https://review.opendev.org/c/openstack/oslo.log/+/852443

Partial-Bug: #1995514
Related-Bug: #1995091
Change-Id: I4bbcfe7db6d75188e61b9084cb02b2dd2aaa0c76

There is a bug in eventlet where logging within a native thread can lead
to a deadlock situation: https://github.com/eventlet/eventlet/issues/432

When encountered with this issue some projects in OpenStack using
oslo.log, eg. Cinder, resolve them by removing any logging withing
native threads.

There is actually a better approach. The Swift team came up with a
solution a long time ago [1], and in this patch that fix is included as
part of the setup method, but will only be run if the eventlet library
has already been loaded.

This patch adds the eventlet library as a testing dependency for the
PipeMutext unit tests.

[1]: https://opendev.org/openstack/swift/commit/69c715c505cf9e5df29dc1dff2fa1a4847471cb6

Closes-Bug: #1983863
Change-Id: Iac1b0891ae584ce4b95964e6cdc0ff2483a4e57d