openstack/swift - swift - OpenDev: Free Software Needs Free Tools

For some reason, when we switched from py36 on centos8 to py39 on
centos9, these two tests started failing. Looks like a disagreement
about whether the canonical path for a bucket request should have
a trailing slash or not.
Mark them as known-failures for now so we can stay aware of any
other new breakage brought on by swift code changes.
Related-Change: I4f6b9c07af7bc768654f1a5d0c66b048e0f2c9c1
Change-Id: If990752c7ef7667182dbe18e49679e48c0e3d42d

The old [files]scripts method of specifying executable Python scripts
triggers some legacy easy-install-like mode for editable installs,
which relies on pkg_resources. Recent versions of setuptools (67.5.0+)
have started emitting warnings when importing pkg_resources, which in
turn cause quite noticeable slowdowns in process startup. This is
particularly prominant on py312, which stopped pre-installing (an often
older version of) setuptools in new venvs.
See also:
 - https://github.com/python/cpython/issues/95299
 - https://github.com/pypa/setuptools/pull/3843
 - https://github.com/pypa/setuptools/issues/3966
Now, use [entry_points]console_scripts to specify these executables,
which does not use pkg_resources in the generated script files.
Change-Id: Ifcc8138e7b55d5b82bea0d411ec6bfcca2c77c83

While switching how some executable scripts were configured, I saw
some strange rolling-upgrade failures that seemed to indicate that
the new invocation method was trying to be used with old code. It
seems like it maybe has something to do with whether swift was
installed to /usr/local/lib/python3.9/site-packages/ or
/usr/local/lib64/python3.9/site-packages/ but I'm not entirely
sure.
At any rate, a proper package manager ought to uninstall the old
version then install the new one, so it seems reasonable to do that
with pip, too.
Change-Id: I12e84745e7601d162755bc9d0f1cda7b63e92197

Under a multi-region deployment with a single Keystone server,
specifying the Keystone auth credentials isn't enough. Indeed,
Castellan succeeds when logging-in, but may use the wrong
Barbican endpoint (if there are 2 Barbican deployed). This is
what happened to us, when deploying our 2nd region.
They way to fix it would be to tell Castellan what region to use,
unfortunately, there's no such option in Castellan. Though we may
specify the barbican_endpoint, which is what this patch allows.
Change-Id: Ib7f4219ef5fdef65e9cfd5701e28b5288741783e

The size in bytes from object metadata of expiring objects are stored in
expirey queue entries under the content_type field.
The x-content-type-timestamp take from object metadata is provided along
with the x-content-type update so the container replicator resolves the
latest content-type and ensures eventual consistency.
UpgradeImpact: During rolling upgrades you should expect expirer queue
entries to continue lacking swift_expirer_bytes= annotations until ALL
object servers replicas have been upgraded to new code.
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: Ie4b25f1bd16def4069878983049b83de06f68e54

Remove swift-tox-py36-centos-8-stream job entirely.
Move the following jobs to CentOS 9:
 - swift-tox-func-s3api-ceph-s3tests-tempauth
 - swift-tox-func-s3api-tests-tempauth
 - swift-multinode-rolling-upgrade, as well as the other rolling
 upgrade jobs
Remove the swift-multinode-rolling-upgrade-victoria job, as py39
support (required for CentOS 9) was not added until wallaby.
Change-Id: I4f6b9c07af7bc768654f1a5d0c66b048e0f2c9c1

There was an abandoned change that made reference to a RecussionError
when running a probe test that imported boto3 that had something to do
with eventlet, ssl and a transitive dependency on requests-mock, but the
fix that actually got merged seemed to depend on another change to
tox.ini that disables request-mock when we run pytest.
Either way, we already import from boto3 at the top of probe tests and
it's in test-requirements; so we require it to be installed even if you
don't have s3api in your pipeline.
Related-Change: I789b257635c031ac0cb6e4b5980f741e0cb5244d
Related-Change: I2793e335a08ad373c49cbbe6759d4e97cc420867
Related-Change: If14e4d2c1af2efcbc99e9b6fe10973a7eb94d589
Change-Id: Id2662bfc5ef2f21f901f1c98e6389c4cb01818a2

Change-Id: Ie5d8b555489d28c3b901e5bbebdcecbde7bb3367

read_conf_for_queue_access was mostly creating an InternalClient, so
make that more explicit.
Change-Id: Ia6e1e6a8b58a8476fa16a3c7d45e620c6d7f88e4

Change-Id: I9413c72f41465fb8026848f71ec3b39fa990c3b7

Drive-by: fix ValueError message for non_negative_int
Change-Id: I06508279d59fa57296dd85548f271a7812aeb45f

We've been working toward separating our logger from our statsd client.
This is generally a good idea; it's always been a little weird to have
our special-case loggers that would allow you to *also* increment some
counters.
The end goal is to take a bunch of places that look like
 logger = utils.get_logger(conf)
 ...
 logger.info(...)
 logger.increment(...)
and turn them into something more like
 logger = logs.get_adapted_logger(conf)
 stats = statsd_client.get_statsd_client(conf, logger=logger)
 ...
 logger.info(...)
 stats.increment(...)
Take a lesson from logging: callers don't need to know whether the
log_level is high enough that their message will be logged, or even
whether logging is enabled at all. Code wanting to emit stats shouldn't
need to know whether statsd collection has been configured, either.
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Change-Id: I6eb5b27a387cc2b7310ee11cc49d38fd2b6cbab8

Even if stdlib socket is probably patched by the time StatsdClient
creates a socket, we want to import the green socket module explicitly
for better testing.
Move test_statsd.py to test_statsd_client.py so it matches the naming
convention of the rest of our test files.
Fix some patching of utils in test_statsd_client to patch
statsd_client.
Rename some vars in test_statsd_client that shadowed the statsd_client
module name.
Move some utils tests out of test_statsd_client and back into
test_utils.
Related-Change: I4b5b12a3b0288b696a39903264741bc862a94ad7
Change-Id: I3de22b7f15dd386fa9c873587782f0dfc4c42a27

Related-Change: I9924ff3b8d7d246631fe61b916823e028e2c01f2
Change-Id: I2a4581e408e3012a44bfb0cd58563b82040e23fc

The old one now just redirects to https://developer.adobe.com/
Change-Id: Iba281bb8dceedef9bbb702abf0b93473bf91d9f7

Change-Id: Ia83ab181277e04e473e33680b3f2d686f534a084

We got fixes everwhere we needed; this actually could have been voting
a while back.
Related-Change: https://review.opendev.org/c/openstack/swift/+/863929
Change-Id: I86012f7f4703becfbc6bb59b865a123cc9823f77

Change-Id: Iba4a9271910b032b8726c0dc605d95cf8da05e44

Change-Id: Ie7da4369152aa5d571a8c834da7390c518143c84

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

Change-Id: I52153d27f53b81de63b6b3590e1ab22f563f178f

Adds ClosingMapper class which is like map() but closes the
iterable.
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Change-Id: Idd0ac21b365a138b065f01d05a257af62ea88177

Change-Id: I4b5b12a3b0288b696a39903264741bc862a94ad7

The boto library was last updated two years ago and has
rusted to the point that it's unusable on py312 -- see
https://github.com/boto/boto/issues/3951
We should transition all of these tests to boto3 equivalents,
but this should help out in the meantime.
Related-Bug: #1557260
Related-Bug: #2063367
Change-Id: If95f45371f352c6a2d16be1a3e1b64e265bccfb4

This shouldn't impact real servers, as those processes were about to
wrap up anyway. It *can* cause some confusing behaviors in tests,
though.
Change-Id: Ifd8a64efcd3fc983596ba7cd9fe28eb9663c93d6

Change-Id: Ief0771dcb17c4ed3d239d60872454e2d35936e39

Change-Id: I68974338f8e0284ed77960048a83f72855b93348

Change-Id: I33e71f6c201bb4f2cf3481afd40cf489eb1fcd1f