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

In keeping with the trend as of late, this change makes FakeSwift behave
more reliably like a real Swift backend.
Swift backend object server's grew support for ignoring Range request
headers when fetching SLO manifests in Jan-2020, and FakeSwift learned
how to mimic the real behavior in Jul-2022. This change unifies the
implementation details with a request_helper and consolidates the
behavior in FakeSwift. It also makes the modern object-server behavior
the default.
Between 2020 and 2022 there was arguably some utility defaulting to
legacy behavior, but in 2023 as we endeavor to refactor the SLO
implementation and extend it's tests: a reliable FakeSwift is paramount.
Since most of the existing tests for SLO's behavior responding to Range
requests did not reliably assert behavior across new and old swift this
change selects the most relevant tests to legacy behavior and has them
opt-in to can_ignore_range = False, while the others merely have their
backend request asserts cleaned-up to match the backend request pattern
you would expect in a production environment that's upgraded in the last
3 years. Additional technical investment may be required to ensure
older clusters can upgrade proxies before object servers w/o tracebacks
until the upgrade finishes; however it appears the existing code is
sufficiently robust despite the lack of explicit multi-inheritance
testing like was done for the legacy manifest format change in Nov-2016
(N.B. unlike rolling upgrade bugs, data is forever).
Related-Change-Id: I4ff2a178d0456e7e37d561109ef57dd0d92cbd4e
Related-Change-Id: If3861e5b9c4f17ab3b82ea16673ddb29d07820a1
Related-Change-Id: Ia6ad32354105515560b005cea750aa64a88c96f9
Change-Id: I7ebfd557b9c8ec25498c628fcf0695cd52ad78d6

The NOTICE log level (25) is added to logging when utils.monkey_patch
is executed. Depending on test execution order, this may not have
happened when some unit tests run, so LogRecords at NOTICE level may
have the default level name of 'Level 25'. FakeLogger doesn't have a
key in its lines dict for 'Level 25', so those tests would blow up.
Closes-Bug: #2034254
Related-Change: I6f35ad41414898fb7dc5da422f524eb52ff2940f
Change-Id: I2945ae725f97ee56e9c7ad580168ec8091f2049a

When a client sends a malformed http request our server returns a valid http error response with Connection: close and closes the connection.
We want to include a transaction-id and ensure we log details about about the "bad request syntax"
Change-Id: Ic0ee1e4fd4d434d442fcffa68da77e862b37d4c6

Thirdy-party middlewares may compose themselves of multiple filters,
similar to what we have done with encryption and versioned_writes.
We should assume they use the get_account_info / get_container_info
APIs, but we cannot assume that they have been updated to pass our
pipeline info through all their layers.
Change-Id: Ic598715f69227f24ebf5617846a84e6bf1115a96

It adds another layer of indirection and state for the sake of labeling;
longer term it'll be easier to be explicit at the point of emission.
Related-Change: I0522b1953722ca96021a0002cf93432b973ce626
Change-Id: Ieebafb19c3fa60334aff2914ab1ae70b8f140342

Change-Id: I193874659536844d431f0c9fa9881e29392ae2b2

This reverts the fallocate- and punch_hole-related parts of commit
c78a5962b5.
Closes-Bug: #2031035
Related-Change: I3e26f8d4e5de0835212ebc2314cac713950c85d7
Change-Id: I8050296d6982f70bb64a63765b25d287a144cb8d

The S3Request class generally tries to set 's3api.backend_path' in the
original request's environ to the path cited by the response to any
swift subrequests that it issues, so that the backend path is logged
by proxy_logging middleware. For example, a multi-part upload request
will be logged usng the segments container and segment object name.
The S3Request class may also check the hash of an object as it is
uploaded using the HashingInput class. If a hash mismatch is detected,
an HTTPUnprocessableEntity exception is raised which previously caused
the setting of 's3api.backend_path' to be bypassed. This patch
therefore modifies the exception handling clause to set
's3api.backend_path' to the swift subrequest's path.
Change-Id: I0ccc6828174bc869ba0604521bdaed0ebc37a408

Change-Id: If17e10d309826b815d2b5b470a8bff071f5c4e87

FakeSwift is complex enough that it warrants some testing of its own.
Change-Id: Ib0e74c3058b74fea26696f2af80278f1072850a3

Change-Id: Ibbe4667d43aba605164a02e0c942174b0b4f841f

The existing FakeSwift implementation already supports using registered
GET responses for GET requests with a query param. It also supports
using registered GET responses for HEAD requests (if they either both
had the exact SAME matching query params, or both did not have ANY query
params). But it did not support using registered GET responses w/o
query params for HEAD requests with a query param, even though a GET
with the same query param would work.
This change makes it a little more consistent: any client or test that
makes a GET request, should be able to make a similar HEAD request and
expect consistent response headers and status.
This test infra improvement is needed as we're going to be extending
test_slo with a bunch of tests that assert consistent response headers
for both GET and HEAD requests w/ new query params.
Change-Id: Idb4020fdeee87a9164312dc9647ab0820b098ff8

While the existing named kwargs (marker, limit, prefix and etc)
are common parameters among different use cases of
direct_get_container, a new 'extra_params' kwarg is added to
support additional private parameters for each individual use case.
Co-Authored-By: Alistair Coles <alistairncoles@gmail.com>
Change-Id: If1d355fbc5d292cee4f44c0e5dc52e5df9ae990b

We added a "safety net" in swob that won't let HEAD responses return a
body. It seems like we don't currently have many unittests that both
enforce leak tracking and ALSO make HEAD requests. The way swob works
currently it's not possible for even a "well behaved client" to get a
clean assert with FakeSwift's leak tracking because the leak tracking
iterator isn't returned to the client to close and swob doesn't do
anything to close down and consume the HEAD response iterator it's
throwing away.
RelatedChange: I168e147aae7c1728e7e3fdabb7fba6f2d747d937
Change-Id: I079315ebeb772eaad1bf190fefd132b4087b4897

All it did was proxy through to NodeIter, anyway.
Change-Id: Ifec8d3a40f00141a73f6e50efe0b53b382ab2ef3

If the proxy-server gets an error (e.g. timeout) while reading data
from a backend node during an object GET then it will increment the
node's error limiting counter. If the node's error counter reaches a
threshold then the node is 'error-limited' i.e. not used for a period
of time.
When a read from a node fails the proxy will also attempt to resume
the read by searching for another useful node to replace the failed
node. Previously, the outcome of this search for a replacement node
erroneously determined whether the failed node's error counter was
incremented or not: the error counter was only incremented if a useful
replacement node was found.
For example, if a read from the last useful primary node failed, and
all handoff nodes then returned 404, the last primary node's would not
have its error counter incremented (for no good reason). However, if a
useful replacement handoff node was found, then the last primary
node's error counter would be incremented.
This patch fixes the inconsistent and confusing handling of node
errors by ensuring that the node error limiting counter is *always*
incremented when reading from a node fails, *before* the search for a
replacement node.
Note: The Related-Change fixed a bug whereby the replacement node's
error counter was incremented rather than the failed node's error
counter. This patch addresses the inconsistent incrementing of the
failed node's error counter.
Related-Change: Ibd405b79820cedaf9cb02906b8c13c8d34f4d7ec
Change-Id: I938ff7ed7bcbfb363f55821cccd92763dfce449d

Fix an AttributeError that may be raised during exception handling in
the proxy object GET path. GetterBase.node was removed by the
RelatedChange.
Change-Id: Icf77b9d6b8065814033059e33aca6e98a633dbd4
RelatedChange: I76ea042ef4b3f5cc1caa4774e35d6191f4ca548e

This patch tries to make the proxy-server GET path a little easier to
read. The changes are primarily to the GetOrHeadHandler and
ECFragGetter classes.
 - Make generator method names more uniform.
 - Use _<method> to make it more obvious which methods are internal
 to the class and which methods are the interface to the class.
 - Move the interface method to the end of the class.
 - Add some commentary and docstrings.
No intended behavioral change.
Change-Id: I3d00b1071669a42526a31588a2643f91c58ea5a8

Change-Id: I35d682e58419f141429877ac6a6964132f7e658b

The proxy GetterBase manages a set of attributes related to the
backend source for a GET response: source (a response object), node
and source_parts_iter. These attributes are always updated together so
benefit from encapsulation, along with some helper methods to simplify
the GET paths.
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: I76ea042ef4b3f5cc1caa4774e35d6191f4ca548e

An s3api bug that mutated statsd prefixes was previously fixed in [1].
The FakeStatsdClient subsequently introduced in [2] enables a more
targeted assertion of the statsd metric name emitted by s3api.
[1] Related-Change: Ia89485bae8f92f4f3d9f5375cab8ff08f70a11a7
[2] Related-Change: I9cdf395e85ab559c2b67b0617f898ad2d6a870d4
Change-Id: Ic2e698f3f62c2ee1f98291c4a7a4e37519471fcd

Currently we simply mock calls in the FakeLogger for calls statsd calls,
and there are also some helper methods for counting and collating
metrics that were called. This Fakelogger is overloaded and doesn't
simulate the real world.
In real life we use a Statsdclient that is attached to the logger.
We've been in the situation where unit tests pass but the statsd client
stacktraces because we don't actually fake the statsdclient based off
the real one and let it's use its internal logic.
This patch creates a new FakeStatsdClient that is based off the real
one, this can then be used (like the real statsd client) and attached to
the FakeLogger.
There is quite a bit of churn in tests to make this work, because we now
have to looking into the fake statsd client to check the faked calls
made.
The FakeStatsdClient does everything the real one does, except overrides
the _send method and socket creation so no actual statsd metrics are
emitted.
Change-Id: I9cdf395e85ab559c2b67b0617f898ad2d6a870d4

Change-Id: I61c7780a84a1f0cee6975da67d08417cf6aa4ea2

The get_own_shard_range() method is called during every container GET
or HEAD request (as well as at other times). The method delegates to
get_shard_ranges() which queries the DB for shard ranges. Although the
query has conditions to only select a single shard range name, and the
method will return only the first matching shard range, the query had
no LIMIT. Adding a LIMIT of 1 significantly reduces execution time
when the DB has many shard range rows.
On the author's machine, using a DB with ~12000 shard ranges this
patch reduces the get_own_shard_range() execution time by a factor of
approximately 100.
Change-Id: I43f79de3f0603b9fab8bf6f7b4c3b1892a8919b3

This patch will add more granularity to metrics of account_info or
container_info cache and related backend lookups.
Before this patch, related metrics are:
 1.account.info.cache.[hit|miss|skip]
 2.container.info.cache.[hit|miss|skip]
With this patch, they are going to become:
 1.account/container.info.infocache.hit
 cache hits with infocache.
 2.account/container.info.cache.hit
 cache hits with memcache.
 3.account/container.info.cache.[miss|skip|disabled]
 .<status_int>
 Those are operations made to backend due to below reasons.
 miss: cache misses.
 skip: the selective skips per skip percentage config.
 disabled: memcache is disabled.
 For each kind of operation metrics, suffix <status_int> will
 count operations with different status. Then a sum of all
 status sub-metrics will the total metrics of that operation.
UpgradeImpact
=============
Metrics dashboard will need updates to display those changed metrics
correctly, also some infocache metrics are newly added, please see
above message for all changes needed.
Change-Id: I60a9f1c349b4bc78ecb850fb26ae56eb20fa39c6

Allow to POST/PUT/DELETE object names with Unicode with sharded container.
Closes-Bug: #2028264
Change-Id: I36acaa35f6443971b9a96374ca7de33059e62c9f

A while back, we changed get_account_info and get_container_info to
call the proxy-server app directly, rather than whatever was right
of the current middleware. This reduced backend request amplification
on cache misses.
However, it *also* meant that we stopped emitting logs or metrics in
the proxy for these backend requests. This was an unfortunate and
unintended break from earlier behavior.
Now, extend the middleware decorating we're doing in loadapp() to
include a "logged app", i.e., the app wrapped by it's right-most
proxy-logging middleware. If there is not logging middleware (such
as would happen for the backend servers), the "logged app" will be
the main app. Make account and container info requests through
*that* app, so we get logging and metrics again.
Closes-Bug: #2027726
Related-Change: I49447c62abf9375541f396f984c91e128b8a05d5
Change-Id: I3f531f904340e4c8407185ed64b41d7d614a308a

The client_chunk_size attribute was introduced into GetOrHeadHandler
for EC support [1]. It was only ever not None for an
ECObjectController. The ECObjectController stopped using
GetOrHeadHandler for Object GET when the ECFragGetter class was
introduced [2], but the EC specific code was not expunged from
GetOrHeadHandler. In [3] the ECFragGetter client_chunk_size was renamed
to fragment_size to better reflect what it represented.
The skip_bytes attribute was similarly introduced for EC support. It
is only ever non-zero if client_chunk_size is an int. For EC,
skip_bytes is used to undo the effect of expanding the backend
range(s) to fetch whole fragments: the range(s) of decoded bytes
returned to the client may need to be narrower than the backend
ranges. There is no equivalent requirement for replicated GETs.
The elimination of client_chunk_size and skip_bytes simplifies the
yielding of chunks from the GetOrHeadHandler response iter.
Related-Change:
[1] I9c13c03616489f8eab7dcd7c5f21237ed4cb6fd2
[2] I0dc5644a84ededee753e449e053e6b1786fdcf32
[3] Ie1efaab3bd0510275d534b5c023cb73c98bec90d
Change-Id: I31ed36d32682469e3c5ca8bf9a2b383568d63c72