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

Something about them threw off the exit-immediately-on-non-zero-exit
behavior when building.
Related-Bug: #2070029
Change-Id: I3e40ebd78a9f8e93c905b24a12f5f54b2d27c2d9

The proxy may use a sub-request to fetch a container listing response,
for example for updating shard ranges. If it then fails to parse the
response, it should use the sub-request path when logging a warning or
error. Before, the proxy would use the original request path which may
have been to an object.
Change-Id: Id904f4cc0f911f9e6e53d4b3ad7f98aacd2b335d

Change-Id: If15c3fee706d295de678f812839a5d0759089ccf

Use same assertion pattern as introduced in the Related-Change and
include the host and port in the assertion.
Change-Id: I7cccf3b8cdfe157c27fb8e0b1f432a649970a865
Related-Change: I9a016de1010dd17e91bc85877413b34d2c3287c7

With labeled metrics on the horizon, I wanted some more end-to-end
tests of stats emission.
Change-Id: I9a016de1010dd17e91bc85877413b34d2c3287c7

It takes a config dict and some caller-specific options, similar to
get_logger. Use this in get_logger, so our logging module doesn't
need to know anything about statsd config options.
Co-Authored-By: yanxiao@nvidia.com
Change-Id: I5ae2cc5c257fb8d7eab885977d9d9cf602224ec7

There's a variety of reasons why s3api may return a 4xx or 5xx
response. It's useful to get some more detail in the log message,
particularly when the request is a HEAD which won't get any detail in
the response body.
Change-Id: I0a499dc5c50bb534a23adcbfe7c3822d8954b0e0

Noticed a few more projects had final py2 releases.
Change-Id: I144efd5ee670a5a6b444fbc31e9434fac31bf2ec

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