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

Add test for mutilated statsd client
Drive-by: revert unncesessary whitespace change in Related-Change.
Related-Change: I3a677bb67c5700da48f89c847f652b4610ba47c2
Co-Authored-By: Shreeya Deshpande <shreeyad@nvidia.com>
Co-Authored-By: Clay Gerrard <cgerrard@nvidia.com>
Change-Id: Id262bbcf0b233f9728f55be208bee5bc146c053d

Change-Id: I14ea6bbd55512e8798e5cadf4f6e68f95961206b

The Related-Changes moved logging and statsd components into new
modules and decoupled statsd from the logs module. This patch attempts
to re-locate the related unit tests to appropriate modules.
* tests for utils functions such as get_logger should be in
 test_utils.py.
* tests for log functions such as get_swift_logger should be in
 test_logs.py.
* tests for statsd client functions should be in
 test_statsd_client.py.
* tests related to patching a SwiftLogAdapter with a StatsdClient
 interface should be in test_utils.py.
Change-Id: I3a677bb67c5700da48f89c847f652b4610ba47c2
Related-Change: I44694b92264066ca427bb96456d6f944e09b31c0
Related-Change: I8988c0add6bb4a65cc8be38f0bf527f141aac48a
Related-Change: Ie73988edf6be0e38d9004bee04ff46c906a759ff
Related-Change: I5ae2cc5c257fb8d7eab885977d9d9cf602224ec7
Related-Change: I4b5b12a3b0288b696a39903264741bc862a94ad7
Related-Change: Ic4b5005e3efffa8dba17d91a41e46d5c68533f9a

It's confusing and unecessary to have the last cycles per-device
object-updater stats reaped from recon immediately during aggregation
and make it impossible to debug stats aggregation.
Drive-by: fix some bugs with stats aggregation
Change-Id: I9df7c2d1c31646a3200614b629598576eb9e64c0

Previously, we were relying on some xfs-specific return order.
Change-Id: If9a0fdb3749a18a9479f20fb174e0c1908a783bb

Previously, it was possible for updater_workers to be a negative integer
or zero. This change enforces that updater_workers should be a positive
integer.
Change-Id: Ie40194b406aeedcf8c38a3c273ab768e2b643a5d

Change-Id: I22674f2e887bdeeffe325efd2898fb90faa4235f

Address an issue where `OldestAsyncManager` instances created before forking resulted in each child process maintaining its own isolated copy-on-write stats, leaving the parent process with an empty/unused instance. This caused the final `dump_recon` call at the end of `run_forever` to report no meaningful telemetry.
The fix aggregates per-disk recon stats collected by each child process. This is done by loading recon cache data from all devices, consolidating key metrics, and writing the aggregated stats back to the recon cache.
Change-Id: I70a60ae280e4fccc04ff5e7df9e62b18d916421e

All we need is int(). Using eval() on user-provided data (or really at
all) is a Bad Idea.
Closes-Bug: #2091124
Change-Id: I39bb87f9d8e27f2f88410a087a120a0e9be1a243

Add some commentary as a reminder that whilst normal object updates to
the ContainerBroker cannot have content-type timestamp older than data
timestamp, expirer queue updates can.
Change-Id: I6d8ad06c645f25497dc15173460430fd93747afa
Related-Change: Ie4b25f1bd16def4069878983049b83de06f68e54

Related-Change: Iba43783e880e0860357ba8b9f0a11f28abf87555
Change-Id: I1e096dab9a97956bf786ccbcd37c20f9a3a5429e

Previously, the OldestAsyncPendingTracker timestamp was stored as a string. This change updates it to be stored as a float.
UpgradeImpact: This will require an additional change to the recon parsers in order to process the timestamp as a float.
Change-Id: Iba43783e880e0860357ba8b9f0a11f28abf87555

Change-Id: I9473fad7c46ac03bbc71328c17e988af9d21386c

Change-Id: Ia03af1680c6230658473c0c8d444efb5bb805f58

Change-Id: Ib8196fe24f8a999315af469a435bd639378c78a9

Our API ref says "Valid values are json, xml, or plain. The default is
plain." There's no reason our tests ought to use an invalid value; it
will confuse anyone looking at tests for how to do a thing.
Note that tests were passing because invalid values are ignored, so
?format=txt behaves exactly like ?format=plain.
Change-Id: I6e119cc9c7297d8aade9736fa1d6f4a105466d77

Currently, when object-server serves PUT request and DiskFile
writer write file chunks to disk, there is no explicit
eventlet sleep called. When network outpace the slow disk IO,
it's possible one large and slow PUT request could cause
eventlet hub not to schedule any other green threads for a
long period of time. To improve this, this patch enable the
configurable yield parameter 'cooperative_period' into object
server controller write path.
Related-Change: I80b04bad0601b6cd6caef35498f89d4ba70a4fd4
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: I1c0aba9830433f093d024b4c39cd3a3b2f0d69f1

We would like to remove any Statsd related code from logs.py. That
requires that SwiftLogAdapter no longer provides a StatsdClient
interface by default. However, for backwards compatibility the main
utils.get_logger/get_prefixed_logger entrypoints must provide a
SwiftLogAdapter that does have a StatdsClient interface.
The new utils._patch_statsd_methods helper function is therefore used
to retrospectively patch a SwiftLogAdapter instance with the
StatsdClient interface when necessary. The _patch_statsd_helper is
used in get_logger, and again when we clone a logger in
get_prefixed_logger.
Co-Authored-By: Shreeya Deshpande <shreeyad@nvidia.com>
Change-Id: I44694b92264066ca427bb96456d6f944e09b31c0

Verify that the reconciler is able to move objects to a container that
has, or will have, versioning enabled, and versions of the moved object
can subsequently be created.
Change-Id: I019447614ebadbb9e2cc8a18c0369bc16a89c0d9

Change-Id: I5c9af73cc66e17dc662d8c4d97cbf71ded1fed6f

A failing CORS test in the gate discovered that, when running with
eventlet==0.38.0, container and account HEAD requests returned
Content-Type of application/json to clients regardless of the requested
format. This was due to the backend HEAD response no longer having a
Content-Length header, causing the listing_formats middleware to not
modify the returned Content-Type (see Related-Change).
The Related-Change fixed the client facing issue by making
listing_formats middleware ensure the correct Content-Type is returned
to clients even when Content-Length is absent in the backend
response. The Related-Change also ensured that the 204 response to
clients always has a Content-Length header.
This patch directly fixes the problem of backend account and container
server HEADs no longer having 'Content-Length: 0' by adding it
explicitly. This violates the RFC prohibition of a 204 response having
a Content-Length header [1], but preserves Swift's historic behavior
and is consistent with the proxy-server's 204 response to clients.
[1] https://httpwg.org/specs/rfc7230.html#header.content-length
Related-Change: If724485e1425d1481d10b9255436301e346f07e8
Change-Id: Idacc59c5f43367926eff5221ee7fc417a9bc2d50

A failing CORS test in the gate discovered that we were responding
application/json to ?format=txt requests (which is maybe not even a
valid value for that qs param?), but only when running with
eventlet==0.38.0
This avoids the problem of backend container server HEADs no longer
having 'Content-Length: 0' by fixing the client HEAD resp headers before
we check for chunked-transfer resp.
Drive-By: refactor listing_formats to use HeaderKeyDict and always set
Content-Length explicitly
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Co-Authored-By: Matthew Oliver <matt@oliver.net.au>
Change-Id: If724485e1425d1481d10b9255436301e346f07e8

This patch fixes a bug in the Related-Change that causes a prefix to
be added twice at the start of an 'exception' log message.
Previously, PrefixLoggerAdapter.exception would forward to the wrapped
LogAdapter.exception, and not call back to
PrefixLoggerAdapter.process. The prefix therefore needed to be added
in both PrefixLoggerAdapter.exception and PrefixLoggerAdapter.process
(for other log level methods).
SwiftLogAdapter.exception *does* call back to SwiftLogAdapter.process,
and so since the Related-Change it is not necessary to add the prefix
in both the SwiftLogAdapter.exception and SwiftLogAdapter.process
methods.
Related-Change: I8988c0add6bb4a65cc8be38f0bf527f141aac48a
Change-Id: Ia6e1f007989b0ef455b8dca8155b386a3fd9e8e1

Give this test file a less specific name in anticipation of further
mpu-related probe tests being added.
Change-Id: Iea01928e1daad25f3425f486b9dda4c6fb58510c

There's an upstream eventlet bug that seems to cause process hangs
during an atexit hook; unfortunately, that means that every time we
call "once" in probe tests, we can hang indefinitely waiting for a
process that won't terminate.
See https://github.com/eventlet/eventlet/issues/989
Now, wait with a timeout; if it pops, kill the offending process and
hope for the best. Do this by patching out subprocess.Popen.wait, but
only in probe tests -- this ensures that we won't impact any real
systems, while also ensuring a broad coverage of probe tests (as
opposed to, say, plumbing some new wait_timeout kwarg into all the
Manager call sites).
Closes-Bug: #2088027
Change-Id: I8983eafbb575d73d1654c354815a7de7ae141873

In order to modernize swift's statsd configuration we're working to
separate it from logging. This change is a pre-requisite for the
Related-Change in order to simplfy the stdlib base logger instance
wrapping in a single extended SwiftLogAdapter (previously LogAdapter)
which supports all the features swift's servers/daemons need
from our logger instance interface.
Related-Change-Id: I44694b92264066ca427bb96456d6f944e09b31c0
Change-Id: I8988c0add6bb4a65cc8be38f0bf527f141aac48a

Otherwise, test-run state (eventlet.tpool initialization, in particular)
can bleed over and cause hangs.
Closes-Bug: #2088026
Change-Id: I4f7dd0755b8dc8806d9b9046ac192d94ca705383

Previously, queue-clean-up would use the same timestamp/offset as the
tombstone written down in the old policy to clean up now-moved data.
This could lead to bad behaviors, as the reconciler-written tombstone
could itself be enqueued to be reconciled, at the same timestamp. If
that happened, replication would never bring the DB replicas to
consistency, causing the reconciler to get different answers for
whether there was work to do.
Now, add an extra offset bump between the tombstone in the old policy
and queue-clean-up. Also add an extra offset to the moved data in the
new policy, to keep it one ahead of queue-clean-up. New ordering looks
like:
- data/ts in old policy at t0 (as well as queue entry time to move it)
- tombstone in old policy at t0_1
- queue clean-up time at t0_2
- moved data/ts in new policy at t0_3
Closes-Bug: #2028175
Change-Id: Ib0dda0d338f48336d18d3d817a0c5994e201042e