commit a1af3811a79963e2e5d1db3e5588cbc9748f9d57
Author: Tim Burke <email address hidden>
Date: Mon Jun 24 12:25:33 2019 -0700
sharding: Cache shard ranges for object writes
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.
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
reconciler: Enqueue right work for shard containers
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.
Reviewed: https:/ /review. opendev. org/671181 /git.openstack. org/cgit/ openstack/ swift/commit/ ?id=ea5cbf633cf a56a418a79cde4c cfea0c1f6f3f92
Committed: https:/
Submitter: Zuul
Branch: feature/losf
commit a1af3811a79963e 2e5d1db3e5588cb c9748f9d57
Author: Tim Burke <email address hidden>
Date: Mon Jun 24 12:25:33 2019 -0700
sharding: Cache shard ranges for object writes
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 updating_ shard_ranges, to control the cache time; it defaults to
this particular update in the proxy. Add a new config option,
recheck_
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: Ic7a732146ea19a 47669114ad5dbee 0bacbe66919
Closes-Bug: 1781291
commit 0ae1ad63c10ea86 43fc0998dca159b 844286c414
Author: zengjia <email address hidden>
Date: Wed Jul 10 15:46:32 2019 +0800
Update auth_url in install docs
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: Id00cfd2c921da3 52abdbbbb6668b9 21f3cb31a1a
Closes-bug: #1754104
commit f4bb1bea28640dc 603da891559387d 6b15f1f2da
Author: Tim Burke <email address hidden>
Date: Wed Jul 10 23:48:39 2019 -0700
reconciler: Enqueue right work for shard containers
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: I79d20209cea70a 6447c4e94941e5e 854889cbec5
Closes-Bug: 1836082
commit c1d170225281a39 973dda1b8e46f5b 3b5c943d1a
Author: Tim Burke <email address hidden>
Date: Wed Jul 10 15:37:44 2019 -0700
functests: Make test_PUT_metadata less flakey
Change-Id: I846e746c2fe759 1a3ab502428f587 e3cbe753225
commit b10f4bae28bec9c 0c394c340bf813a 28ac8a3380
Author: Tim Burke <email address hidden>
Date: Tue Jun 18 09:54:02 2019 -0700
func tests: tolerate more 404s when deleting
Change-Id: I3129e4f94ac399 64f2f17ea05b6b2 dd807fba82a
commit 557335465561b7a 00d08cc5a370d5f cd6e7d83b0
Author: Tim Burke <email address hidden>
Date: Sat Jun 1 10:46:54 2019 -0700
Move calls to self.app outside of error handling
On py3, if/when you hit an error, you can get very noisy tracebacks like
<traceback coming out of split_path()>
During handling of the above exception, another exception occurred:
<meaningful traceback>
In general, I like this, but when we've used exception handling for
flow-control, it gets difficult to separate the wheat from the chaff.
Change-Id: I5f3bc6416207ca b2c7e3a77ee6689 360b55990e7
commit 06e4533c2e04333 e6215fcaed96911 8cb758d3d3
Author: Tim Burke <email address hidden>
Date: Mon Jun 10 13:47:30 2019 -0700
py3: Fix header_ to_environ_ key
When doing things for the sake of WSGI, .upper(), .title() etc. should
only be used on bytes.
Change-Id: I130ba5014b7eff 458d87ab29eb42f e45607c9a12