Comment 26 for bug 1754104

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/losf)

Reviewed: https://review.opendev.org/671181
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=ea5cbf633cfa56a418a79cde4ccfea0c1f6f3f92
Submitter: Zuul
Branch: feature/losf

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.

    Change-Id: Ic7a732146ea19a47669114ad5dbee0bacbe66919
    Closes-Bug: 1781291

commit 0ae1ad63c10ea8643fc0998dca159b844286c414
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: Id00cfd2c921da352abdbbbb6668b921f3cb31a1a
    Closes-bug: #1754104

commit f4bb1bea28640dc603da891559387d6b15f1f2da
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: I79d20209cea70a6447c4e94941e5e854889cbec5
    Closes-Bug: 1836082

commit c1d170225281a39973dda1b8e46f5b3b5c943d1a
Author: Tim Burke <email address hidden>
Date: Wed Jul 10 15:37:44 2019 -0700

    functests: Make test_PUT_metadata less flakey

    Change-Id: I846e746c2fe7591a3ab502428f587e3cbe753225

commit b10f4bae28bec9c0c394c340bf813a28ac8a3380
Author: Tim Burke <email address hidden>
Date: Tue Jun 18 09:54:02 2019 -0700

    func tests: tolerate more 404s when deleting

    Change-Id: I3129e4f94ac39964f2f17ea05b6b2dd807fba82a

commit 557335465561b7a00d08cc5a370d5fcd6e7d83b0
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: I5f3bc6416207cab2c7e3a77ee6689360b55990e7

commit 06e4533c2e04333e6215fcaed969118cb758d3d3
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: I130ba5014b7eff458d87ab29eb42fe45607c9a12