Previously, we issued a GET to the root container for every object PUT,
POST, and DELETE. This puts load on the container server, potentially
leading to timeouts, error limiting, and erroneous 404s (!).
Now, cache the complete set of 'updating' shards, and find the shard for
this particular update in the proxy. Add a new config option,
recheck_updating_shard_ranges, to control the cache time; it defaults to
one hour. Set to 0 to fall back to previous behavior.
Note that we should be able to tolerate stale shard data just fine; we
already have to worry about async pendings that got written down with
one shard but may not get processed until that shard has itself sharded
or shrunk into another shard.
Also note that memcache has a default value limit of 1MiB, which may be
exceeded if a container has thousands of shards. In that case, set()
will act like a delete(), causing increased memcache churn but otherwise
preserving existing behavior. In the future, we may want to add support
for gzipping the cached shard ranges as they should compress well.
Change-Id: Ic7a732146ea19a47669114ad5dbee0bacbe66919
Closes-Bug: 1781291
Beginning with the Queens release, the keystone install guide
recommends running all interfaces on the same port.This patch
updates the swift install guide to reflect that change
Change-Id: Id00cfd2c921da352abdbbbb6668b921f3cb31a1a
Closes-bug: #1754104
This fixes newly-enqueued work going forward, but doesn't offer anything
to try to parse existing bad work items or even to kick shards so they
reset their reconciler high-water marks.
Change-Id: I79d20209cea70a6447c4e94941e5e854889cbec5
Closes-Bug: 1836082
Drive-by: Tighten domain_remap assertions on listings, which required
that we fix proxy pipeline placement. Add a note about it to the sample
config.
Change-Id: I41835148051294088a2c0fb4ed4e7a7b61273e5f
Previously this had no timeout, which meant that the replicator might
hang and fail to make progress indefinitely while trying to receive
shard ranges.
While we're at it, only call get_shard_ranges when the remote indicates
that it has shard ranges for us to sync -- this reduces the number of
requests necessary to bring unsharded replicas in sync.
Change-Id: I32f51f42d76db38271442a261600089404a00f91
Closes-Bug: #1835260
Apparently Python's stdlib got more picky about what a header should
look like. As a result, if an account, container, or object had a
non-ASCII metadata name (values were fine), the proxy-server wouldn't
parse all of the headers. See https://bugs.python.org/issue37093 for
more information.
This presented several problems:
- Since the non-ASCII header aborts parsing, we may lose important
HTTP-level information like Content-Length or Transfer-Encoding.
- Since the offending header wouldn't get parsed, the client wouldn't
even know what the problem was.
- Even if the client knew what the bad header was, it would have no way
to clear it, as the server uses the same logic to parse incoming
requests.
So, hack in our own header parsing if we detect that parsing was
aborted. Note that we also have to mangle bufferedhttp's putheader so we
can get non-ASCII headers to the backend servers.
Now, we can run the test_unicode_metadata tests in
test/functional/test_account.py and test/functional/test_container.py
under py2 against services running under py3.
Change-Id: I0f03c211f35a9a49e047a5718a9907b515ca88d7
"self.assertTrue(policies[1].is_deprecated, True)" and
"self.assertTrue(crashy_calls[0], 1)" are not correct, this is
to fix them.
Change-Id: I7b07f0833d675d2939c910f679b54da2b8cda482
There are few things more frustrating when digging through a log than
finding a traceback that ends with
raise InternalError('unexpected status code %d' % status)
while having no indication of what the status code was.
Change-Id: I08e9f7c0643ae0469bd1937a30c1c4477b67c31f
PUT request on an existing container will trigger an update on
container db. When disks where container db landed are under
heavy loads, update on the container db may fail due to LockTimout.
Hence, we first check existence, if it's not there, we PUT.
Change-Id: Ic61153948e35f1c09b05bfc97dfac3fb487b0898
Closes-Bug: 1780204
Sometimes we want 404, sometimes we want 503 - it's tricky
Change-Id: I30f5af07e2e1fc7cbb6bdb1c334a0a161caf0906
Related-Change-Id: I53ed04b5de20c261ddd79c98c629580472e09961
Note that keystone wants to stick some UTF-8 encoded bytes into
memcached, but we want to store it as JSON... or something?
Also, make sure we can hit memcache for containers with invalid UTF-8.
Although maybe it'd be better to catch that before we ever try memcache?
Change-Id: I1fbe133c8ec73ef6644ecfcbb1931ddef94e0400
Otherwise, paste complains about not being able to interpolate values
into the replication_semaphore. As long as it gets dropped in before we
fork(), I think it's OK?
Closes-Bug: 1691075
Change-Id: Ib7e065c47871876786bcc9ff39737f5d1bb3c12c
This patch ports the tempurl middleware over to PY3. We use
an "all-native" string model, where we convert WSGI strings
as soon as we see them. It helps to deal with HMAC.
Aaand, we fix formpost along the way. It _clearly_ was
doing a wrong thing, encoding the same body several times
if we had several keys. On py2 it wasn't noticeable, but
on py3 this breaks, because the bytes type cannot be encoded
again.
Change-Id: I69974cc8a39731c980b54137b799a36b2e63a44a
