Reviewed:  https://review.openstack.org/535990
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=3122895118111b2b11f5ef9d0b3410b337624b1b
Submitter: Zuul
Branch:    feature/deep

commit ddb13aa5eab03b6993887eb02260b4bc0b256922
Author: vxlinux <email address hidden>
Date:   Sat Jan 20 17:23:35 2018 +0800

    Remove redundant blank space in README.rst
    
    Change-Id: If347476e3b9185921ff174d3f8170a1c4d0622e8

commit 12f874534925b52f9d1c91580794eb9e5e9a4589
Author: vxlinux <email address hidden>
Date:   Fri Jan 19 16:54:26 2018 +0800

    Add Docstrings to validate_replicas_by_tier
    
    New common functions should have Docstrings
    
    Change-Id: Icbb3cdf38509fd6d034cbb2271786559780a7b68

commit d2034cd7b6946829a7d95c4d2c71d4322f80e855
Author: Clay Gerrard <email address hidden>
Date:   Tue Jan 16 17:03:38 2018 -0800

    Keep object-updater stats logging consistent
    
    If we're going to encapsulate the stats tracking it seems reasonable if
    we ever add any more metrics we can reduce the number of places we need
    to update log messages.
    
    Change-Id: I187cf6cfec1e0a9138b709fa298e1991aa809ec4

commit cd2c73fd955317a3f40758cef45ee48bef8fbc79
Author: Tim Burke <email address hidden>
Date:   Tue Jan 16 01:07:35 2018 +0000

    internal_client: Don't retry when we expect the same reponse
    
    This boils down to 404, 412, or 416; or 409 when we provided an
    X-Timestamp.
    
    This means, among other things, that the expirer won't issue 3 DELETEs
    every cycle for every stale work item.
    
    Related-Change: Icd63c80c73f864d2561e745c3154fbfda02bd0cc
    Change-Id: Ie5f2d3824e040bbc76d511a54d1316c4c2503732

commit 222df9185782f59ffdc96c3534afaa2fb1361235
Author: chengebj5238 <email address hidden>
Date:   Thu Jan 18 17:03:11 2018 +0800

    Modify redirection URL and broken URL
    
    Change-Id: I9a04cb2fbe61e1fbd8185ab2fac9abbcea4d55cc

commit d1656e334959e09d13eea98c2696e58c77e4ab91
Author: Tim Burke <email address hidden>
Date:   Fri Jan 12 13:17:45 2018 -0800

    slo: Send ETag header in 206 responses
    
    Why weren't we doing that before?? The etag should be the same as for
    GET/HEAD, and by sending it, we can assure resuming clients that they're
    downlading the same object even if they didn't include an If-Match
    header.
    
    Change-Id: I4ccbd1ae3a909ecb4606ef18211d1b868f5cad86
    Related-Change: Ic11662eb5c7176fbf422a6fc87a569928d6f85a1

commit 88eea33ccd1875af811b59d15df55e2bffa27f77
Author: Clay Gerrard <email address hidden>
Date:   Thu Jan 11 13:36:09 2018 -0800

    Recenter builder test expectation around random variance
    
    ... in order to make the test pass with more seeds and fail less
    frequently in the gate.
    
    Change-Id: I059e80af87fd33a3b6c0731fbad62e035215eca5

commit f64c00b00aa8df31a937448917421891904abdc8
Author: Samuel Merritt <email address hidden>
Date:   Fri Jan 12 07:17:18 2018 -0800

    Improve object-updater's stats logging
    
    The object updater has five different stats, but its logging only told
    you two of them (successes and failures), and it only told you after
    finishing all the async_pendings for a device. If you have a cluster
    that's been sick and has millions upon millions of async_pendings
    laying around, then your object-updaters are frustratingly
    silent. I've seen one cluster with around 8 million async_pendings per
    disk where the object-updaters only emitted stats every 12 hours.
    
    Yes, if you have StatsD logging set up properly, you can go look at
    your graphs and get real-time feedback on what it's doing. If you
    don't have that, all you get is a frustrating silence.
    
    Now, the object updater tells you all of its stats (successes,
    failures, quarantines due to bad pickles, unlinks, and errors), and it
    tells you incremental progress every five minutes. The logging at the
    end of a pass remains and has been expanded to also include all stats.
    
    Also included is a small change to what counts as an error: unmounted
    drives no longer do. The goal is that only abnormal things count as
    errors, like permission problems, malformed filenames, and so
    on. These are things that should never happen, but if they do, may
    require operator intervention. Drives fail, so logging an error upon
    encountering an unmounted drive is not useful.
    
    Change-Id: Idbddd507f0b633d14dffb7a9834fce93a10359ab

commit d924fa759967b7cdca0d91f21112725f6099a254
Author: Samuel Merritt <email address hidden>
Date:   Tue Jan 16 22:19:09 2018 -0800

    Remove old post-as-copy leftovers from tests.
    
    Since commit 1e79f828, we don't need to test with post_as_copy=True
    any more since we haven't got post_as_copy at all.
    
    Change-Id: I9c96ce0b812d877bbe11bdb50eb160d6ffa5933d

commit dfa0c4e604fb931d232395599bd0e7b0f11441ee
Author: Alistair Coles <email address hidden>
Date:   Wed Jan 17 12:04:45 2018 +0000

    Preserve expiring object behaviour with old proxy-server
    
    The related change [1] causes expiring object records to no longer be
    created if the X-Delete-At-Container header is not sent to the object
    server, but old proxies prior to [2] (i.e. releases prior to 1.9.0)
    did not send this header.
    
    The goal of [1] can be alternatively achieved by making expiring
    object record creation be conditional on the X-Delete-At-Host header.
    
    [1] Related-Change: I20fc2f42f590fda995814a2fa7ba86019f9fddc1
    [2] Related-Change: Id0873a3f2198ce285fe0b0c777738eff38bc2438
    
    Change-Id: Ia0081693f01631d3f2a59612308683e939ced76a

commit 745581ff2f5b2c6f6340eb60918d8ba842297f89
Author: Samuel Merritt <email address hidden>
Date:   Tue Jan 9 19:19:36 2018 -0800

    Don't make async_pendings during object expiration
    
    After deleting an object, the object expirer deletes the corresponding
    row from the expirer queue by making DELETE requests directly to the
    container servers. The same thing happens after attempting to delete
    an object, but failing because the object has already been deleted. If
    the DELETE requests fail, then the expirer will encounter that row
    again on its next pass and retry the DELETE at that time. Therefore,
    it is not necessary for the object server to write an async_pending
    for that queue row's deletion.
    
    Currently, however, two of the object servers do write such
    async_pendings. Given Rc container replicas, that's 2 * Rc updates
    from async_pendings and another Rc from the object expirer
    directly. Given a typical Rc of 3, that's 9 container updates per
    expiring object.
    
    This commit makes the object server write no async_pendings for DELETE
    requests coming from the object expirer. This reduces the number of
    container server requests to Rc (typically 3), all issued directly
    from the object expirer.
    
    Closes-Bug: 1076202
    Change-Id: Icd63c80c73f864d2561e745c3154fbfda02bd0cc

commit d707fc7b6d0ceb4556dddfc258c5de8c4baff05c
Author: Clay Gerrard <email address hidden>
Date:   Tue Jan 16 16:30:13 2018 -0800

    DRY out tests until the stone bleeds
    
    Can we go deeper!?
    
    Change-Id: Ibd3b06542aa1bfcbcb71cc98e6bb21a6a67c12f4

commit ba8f1b1c3786df4e79fc3f9e4747d7cfb9072b6f
Author: Alistair Coles <email address hidden>
Date:   Wed Jan 17 15:25:33 2018 +0000

    Fix intermittent unit test failure
    
    test_check_delete_headers_removes_delete_after was
    failing intermittently due to rounding of float time
    values.
    
    Change-Id: Ia126ad6988f387bbd2d1f5ddff0a56d457a1fc9b
    Closes-Bug: #1743804

commit e747f94313f315fdf8d8fc01fb0c5aac60c33897
Author: Kota Tsuyuzaki <email address hidden>
Date:   Wed Dec 27 14:37:29 2017 +0900

    Fix InternalClient to drain response body if the request fails
    
    If we don't drain the body, the proxy logging in the internal client
    pipeline will log 499 client disconnect instead of actual error response
    code.
    
    For error responses, we try to do the most helpful thing using swob's
    closing and caching response body attribute.  For non-error responses
    which are returned to the client, we endeavour to keep the app_iter
    intact and unconsumed, trusting expecting the caller to do the right
    thing is the only reasonable interface.  We must cleanly close any WSGI
    app_iter which we do not return to the client regardless of status code
    and allow the logging of the 499 if needed.
    
    Closes-Bug: #1675650
    Change-Id: I455b5c38074ad0e72aa5e0b05771e193208905eb

commit d8f9045518035cbd1a40d0a94227952a384143ec
Author: Christopher Bartz <email address hidden>
Date:   Fri Dec 1 11:13:10 2017 +0100

    Send correct number of X-Delete-At-* headers
    
    Send just as many requests with X-Delete-At-* as we do X-Container-* to
    the object server.  Furthermore, stop the object server on making an
    update to the expirer queue when it wasn't told to do so and remove the
    log warning which would have been produced.
    
    Reason:
    
    It can be the case that the number of object replicas (OR) is larger
    than the number of container replicas (CR) for a given storage policy
    (most likely in case of EC).  Before this commit, only CR object servers
    received the x-delete-at-* headers, which means that OR - CR object
    servers did not receive the headers.  The servers missing the header
    would produce a log warning and create the x-delete-at-container header
    and async update on their own, which could lead to a bug, if the
    expiring_objects_container_divisor option was misconfigured.
    
    Change-Id: I20fc2f42f590fda995814a2fa7ba86019f9fddc1
    Closes-Bug: #1733588

commit cf1a1e89bbca50e285e99d31209c6eac6c697083
Author: Tim Burke <email address hidden>
Date:   Wed Aug 23 07:25:09 2017 +0000

    expirer: unexpected responses don't warrant tracebacks
    
    If you want more information, you need to go check out the *other* node.
    
    Maybe this should be further refined to only log at debug for specific
    statuses like 404 and 412?
    
    Partial-Bug: 1688558
    Related-Bug: 1455221
    Change-Id: Ieefd8841154faba40dcf2a03abc5f056bdccd54f

commit 56b84c9295f3860a1fa0033774a7498105a1597f
Author: Samuel Merritt <email address hidden>
Date:   Tue Jan 16 12:02:13 2018 -0800

    Minor cleanup in monitoring doc.
    
    Change-Id: Ia21f8743bfd745f2579db8658624f888461c2cc2

commit bc6fb8995123d08e672bdcf55bd35165509d60d9
Author: Monty Taylor <email address hidden>
Date:   Tue Jan 16 11:32:12 2018 -0600

    Add a note about the cost of COPY for setting metadata
    
    The pointer to using COPY to the same object as a mechanism to set only
    a subset of the metadata, it does not mention that doing so results in
    a full copy of the object in question on the backend.
    
    Add a note so it's clear that there is a tradeoff involved.
    
    Change-Id: I0c20a4909a6c3ff672f753d26cb9fb2f5f33d1f4

commit 0d324c16deacbd025314bd2211c824aa971a65b8
Author: guotao <email address hidden>
Date:   Tue Jan 16 14:28:41 2018 +0800

    Update http with https
    
    Use https instead of http for some links in readme.rst
    
    Change-Id: Idd382f58108e96129c69c6dc149c694fd7833fb3

commit 6e394bba0a783cf6bf06c6f60d4ccda150a87e67
Author: Alistair Coles <email address hidden>
Date:   Mon Jan 15 15:16:08 2018 +0000

    Add request_tries option to object-expirer.conf-sample
    
    ...and update the object-expirer man page.
    
    Change-Id: Idca1b8e3b7d5b40481af0d60477510e2557b88c0

commit 68906dac43ac4e0a2a7e9ee62d9893138369b27a
Author: Clay Gerrard <email address hidden>
Date:   Tue Jan 9 11:16:15 2018 -0800

    Further extract a builder method to a util function
    
    ... to make testing more targeted and obvious
    
    Related-Change-Id: I89439286b211f2c5ef19deffa77c202f48f07cf8
    Change-Id: I93b99128a4fb35395e8e9caf11649e216f824fdf

commit a1ae142d5bcaf83ddde568ba4b957e23cc2b5e1c
Author: vxlinux <email address hidden>
Date:   Thu Jan 4 16:18:37 2018 +0800

    Merge repeat code for rebalance
    
    There are three similar code segments in rebalance process as follows：
    
        tiers = ['cluster', 'regions', 'zones', 'servers', 'devices']
        for i, tier_name in enumerate(tiers):
            replicas_at_tier = sum(weighted_replicas_by_tier[t] for t in
                                   weighted_replicas_by_tier if len(t) == i)
            if abs(self.replicas - replicas_at_tier) > 1e-10:
                raise exceptions.RingValidationError(
                    '%s != %s at tier %s' % (
                        replicas_at_tier, self.replicas, tier_name))
    
    I think we can encapsulate this code segment to a private function and
    replace those code segments with a function call
    
    Change-Id: I89439286b211f2c5ef19deffa77c202f48f07cf8

commit 5cbd5cf303ca085af2a61dbb5b98d1b98099bd7e
Author: cheng <email address hidden>
Date:   Mon Jan 15 12:05:39 2018 +0800

    Return HTTPServerError instead of HTTPNotFound
    
    Swift allows autocreate account. It should be treat as server error
    instead of 404 when it fails to create account
    
    Change-Id: I726271bc06e3c1b07a4af504c3fd7ddb789bd512
    Closes-bug: 1718810

commit a9964a7fc3df5e16d066914498e83ac065282e2e
Author: Thiago da Silva <email address hidden>
Date:   Thu Jan 11 07:15:48 2018 -0500

    fix barbican integration
    
    Added auth_url to the context we pass to castellan
    library. In a change [1] intended to deprecate the use
    of auth_endpoint passed as the oslo config, it actually
    completely removed the use of it[2], so this change became
    necessary or the integration is broken.
    
    [1] - https://review.openstack.org/#/c/483457
    [2] - https://review.openstack.org/#/c/483457/6/castellan/key_manager/barbican_key_manager.py@143
    
    Change-Id: I933367fa46aa0a3dc9aedf078b1be715bfa8c054

commit 35ad4e874522dd749582233ead8a023e042493bb
Author: Alistair Coles <email address hidden>
Date:   Fri Jan 12 17:26:26 2018 +0000

    Add tests for X-Backend-Clean-Expiring-Object-Queue true
    
    Check that when X-Backend-Clean-Expiring-Object-Queue is true
    the object server does indeed call async_update.
    
    Change-Id: I0a87979147591f15349b868a12ac6dd15ac4e37f
    Related-Change: I4d64f4d1d107c437fd3c23e19160157fdafbcd42

commit 7afc6a06eed1e9e3fdbea756074111b8a209d266
Author: Clay Gerrard <email address hidden>
Date:   Thu Jan 11 14:21:39 2018 -0800

    Remove un-needed hack in probetest
    
    If you ran this probe test with ssync before the related change it would
    demonstrate the related bug.  The hack isn't harmful, but it isn't
    needed anymore.
    
    Related-Change-Id: I7f90b732c3268cb852b64f17555c631d668044a8
    Related-Bug: 1652323
    
    Change-Id: I09e3984a0500a0f4eceec392e7970b84070a5b39

commit 55a1b63db501f18ba62e86a29db47465dce8eb26
Author: Clay Gerrard <email address hidden>
Date:   Wed Jan 10 15:53:06 2018 -0800

    Let recon-cron work with conf.d
    
    Change-Id: I862b74e0d9b20ba149581c1add6473dc1e5b2859

commit 48da3c1ed783a2b69cc74b02e8fd45e9d36cf80a
Author: Samuel Merritt <email address hidden>
Date:   Tue Jan 9 13:27:48 2018 -0800

    Limit object-expirer queue updates on object DELETE, PUT, POST
    
    Currently, on deletion of an expiring object, each object server
    writes an async_pending to update the expirer queue and remove the row
    for that object. Each async_pending is processed by the object updater
    and results in all container replicas being updated. This is also true
    for PUT and POST requests for existing expiring objects.
    
    If you have Rc container replicas and Ro object replicas (or EC
    pieces), then the number of expirer-queue requests made is Rc * Ro [1].
    
    For a 3-replica cluster, that number is 9, which is not terrible. For
    a cluster with 3 container replicas and a 15+4 EC scheme, that number
    is 57, which is terrible.
    
    This commit makes it so at most two object servers will write out the
    async_pending files needed to update the queue, dropping the request
    count to 2 * Rc [2]. The object server now looks for a header
    "X-Backend-Clean-Expiring-Object-Queue: <true|false>" and writes or
    does not write expirer-queue async_pendings as appropriate. The proxy
    sends that header to 2 object servers.
    
    The queue update is not necessary for the proper functioning of the
    object expirer; if the queue update fails, then the object expirer
    will try to delete the object, receive 404s or 412s, and remove the
    queue entry. Removal on object PUT/POST/DELETE is helpful but not
    required.
    
    [1] assuming no retries needed by the object updater
    
    [2] or Rc, if a cluster has only one object replica
    
    Change-Id: I4d64f4d1d107c437fd3c23e19160157fdafbcd42

commit 9754a2ebe3f0ef66efd6fe0ff6c32fbb2e992617
Author: Christian Schwede <email address hidden>
Date:   Wed Jan 10 11:35:00 2018 +0100

    Change exit code when displaying empty rings
    
    Displaying an empty ring should not be an error, thus
    changing the exit code back to the former value of 0.
    
    Closes-Bug: 1742417
    Change-Id: I779c30cff1b4d24483f993221a8c6d944b7ae98d

commit a41c458c90b12c52688dd8b2b8a818b79b4e9693
Author: Samuel Merritt <email address hidden>
Date:   Fri Jan 5 16:54:44 2018 -0800

    proxy: make the right number of container updates
    
    When the proxy is putting X-Container headers into object PUT
    requests, it should put out just enough to make the container update
    durable in the worst case. It shouldn't do more, since that results in
    extra work for the container servers; and it shouldn't do less, since
    that results in objects not showing up in listings.
    
    The current code gets the number right as long as you have 3 container
    replicas and an odd number of object replicas, but it comes up with
    some bogus numbers in other cases. The number it computes is
    (object-quorum + 1).
    
    This patch changes the number to (container-quorum +
    max_put_failures).
    
    Example: given an EC 12+5 policy and 3 container replicas, you can
    lose up to 4 connections and still succeed. Since you need to have 2
    container updates happen for durability, you need 6 connections to
    have X-Container headers. That way, you can lose 4 and still have 2
    left. The current code would put X-Container headers on 14 of the
    connections, resulting in more than double the workload on the
    container servers; this patch changes the number to 6.
    
    Example 2: given a (crazy) EC 3+6 policy and 3 container replicas, you
    can lose up to 5 connections, so you need X-Container headers on
    7. The current code only sends 5, giving a worst-case result of a PUT
    succeeds but never reaches the containers. This patch changes the
    number to 7.
    
    Other examples:
                              |  current  |  this change  |
                            --+-----------+---------------+
    EC 10+4, 3x container     |    12     |      5        |
    EC 10+4, 5x container     |    12     |      6        |
    EC 15+4, 3x container     |    17     |      5        |
    EC 15+4, 5x container     |    17     |      6        |
    EC 4+8, 3x container      |    6      |      9        |
    7x object, 3x container   |    5      |      5        |
    6x object, 3x container   |    4      |      5        |
    
    Change-Id: I34efd48655b890340912810ab111bb63445e5c8b

commit e7ffda5d0b75bd85c3b886c3aad0c938c7d476d6
Author: Alistair Coles <email address hidden>
Date:   Fri Jan 5 17:41:21 2018 +0000

    Use _update_x_timestamp method in object controller DELETE method
    
    The DELETE method repeats inline the same behaviour as provided by
    _update_x_timestamp, so just call the method.
    
    Also add unit tests for the behaviour of _update_x_timestamp.
    
    Change-Id: I8b6cfdbfb54b6d43ac507f23d84309ab543374aa

commit bf13d64cd07c0957a88687a24a8ca861189fb5ac
Author: Matthew Oliver <email address hidden>
Date:   Wed Jan 3 04:48:44 2018 +0000

    Show devices marked as deleted on empty rings
    
    This is a follow up patch to 530258 which will show
    extra infromation on empty rings.
    
    This patch goes one step further. On a completely empty ring:
    
      $ swift-ring-builder my.builder create  8 3 1
      $ swift-ring-builder my.builder
      my.builder, build version 0, id 33b4e117056340feae7d40430180c6bb
      256 partitions, 3.000000 replicas, 0 regions, 0 zones, 0 devices, 0.00 balance, 0.00 dispersion
      The minimum number of hours before a partition can be reassigned is 1 (0:00:00 remaining)
      The overload factor is 0.00% (0.000000)
      Ring file my.ring.gz not found, probably it hasn't been written yet
      Devices:   id region zone ip address:port replication ip:port  name weight partitions balance flags meta
      There are no devices in this ring, or all devices have been deleted
    
    It will still start the device list and then say no devices.. Why. let's
    see what happens now on an empty ring with devices still marked as
    deleted:
    
      $ swift-ring-builder my.builder add r1z1-127.0.0.1:6010/sdb1 1
      Device d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_"" with 1.0 weight got id 0
      $ swift-ring-builder my.builder add r1z1-127.0.0.1:6010/sdb2 1
      Device d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_"" with 1.0 weight got id 1
      $ swift-ring-builder my.builder remove r1z1-127.0.0.1
      Matched more than one device:
          d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_""
          d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_""
      Are you sure you want to remove these 2 devices? (y/N) y
      d0r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb1_"" marked for removal and will be removed next rebalance.
      d1r1z1-127.0.0.1:6010R127.0.0.1:6010/sdb2_"" marked for removal and will be removed next rebalance.
    
      $ swift-ring-builder my.builder
      my.builder, build version 4, id 33b4e117056340feae7d40430180c6bb
      256 partitions, 3.000000 replicas, 1 regions, 1 zones, 2 devices, 0.00 balance, 0.00 dispersion
      The minimum number of hours before a partition can be reassigned is 1 (0:00:00 remaining)
      The overload factor is 0.00% (0.000000)
      Ring file my.ring.gz not found, probably it hasn't been written yet
      Devices:   id region zone ip address:port replication ip:port  name weight partitions balance flags meta
                  0      1    1  127.0.0.1:6010      127.0.0.1:6010  sdb1 0.00          0    0.00   DEL
                  1      1    1  127.0.0.1:6010      127.0.0.1:6010  sdb2 0.00          0    0.00   DEL
      There are no devices in this ring, or all devices have been deleted
    
    Now even when all devices are removed we can still see them as they are still there, only marked as deleted.
    
    Change-Id: Ib39f734deb67ad50bcdad5333cba716161a47e95

commit e343452394780b1f555777bc7083912ac68633d3
Author: Tim Burke <email address hidden>
Date:   Mon Jan 8 20:02:50 2018 +0000

    Support existing builders with None _last_part_moves
    
    These were likely written before the first related change, or created
    from an existing ring file.
    
    Also, tolerate missing dispersion when rebalancing -- that may not exist
    in the builder file.
    
    Change-Id: I26e3b4429c747c23206e4671f7c86543bb182a15
    Related-Change: Ib165cf974c865d47c2d9e8f7b3641971d2e9f404
    Related-Change: Ie239b958fc7e0547ffda2bebf61546bd4ef3d829
    Related-Change: I551fcaf274876861feb12848749590f220842d68

commit 94565d9137275f4c6c775835cf2c0b81693137be
Author: Alistair Coles <email address hidden>
Date:   Mon Jan 8 10:14:06 2018 +0000

    Disallow x-delete-at equal to x-timestamp
    
    Previously an x-delete-at value equal to the x-timestamp value was
    allowed.  This could only occur when x-timestamp happened to take an
    integer value and would result in an object that was immediately
    unreadable.
    
    Similarly an x-delete-after value of zero may previously have been
    accepted if x-timestamp happened to be an integer value.
    
    With this change an x-delete-at value equal to x-timestamp or an
    x-delete-after value of zero always results in a 400 BadRequest.
    
    Also cleans up check_delete_headers docstring.
    
    Related-Change: Ia8d00fcef8893e3b3dd5720da2c8a5ae1e6e4cb8
    Related-Change: Ib2483444d3999e13ba83ca2edd3a8ef8e5c48548
    Change-Id: I27fdd800d8e149302ff4d6531101e9726a14d471

commit 79ac3a3c311b393d7b64ce4c41d68b52801b52cb
Author: Alistair Coles <email address hidden>
Date:   Mon Jan 8 14:36:53 2018 +0000

    Fix intermittent check_delete_headers failure
    
    Use a utils.Timestamp object to set a more realistic x-timestamp
    header to avoid intermittent failure when str(time.time()) results
    in a rounded up value.
    
    Closes-Bug: 1741912
    Change-Id: I0c54d07e30ecb391f9429e7bcfb782f965ece1ea

commit 6151554a89216934c0be242b93b28d87adc421e0
Author: Alistair Coles <email address hidden>
Date:   Fri Jan 5 14:44:52 2018 +0000

    Correct 400 response message when x-delete-after is zero
    
    Before an x-delete-after header with value '0' would almost
    certainly result in a 400 response, but the response body would
    report a problem with x-delete-at. Now the response correctly
    blames the x-delete-after header.
    
    Related-Change: I9a1b6826c4c553f0442cfe2bb78cdf49508fa4a5
    Change-Id: Ia8d00fcef8893e3b3dd5720da2c8a5ae1e6e4cb8

commit b22d3c1115609a62b3fce5177be213ed3fa587c5
Author: xhancar <email address hidden>
Date:   Sat Jan 6 20:48:10 2018 +0000

    fix of type error
    
    There was incorrect path starting /home/swift, but /home/<your-user-name> is correct for common users.
    
    Change-Id: Ia81b2119c87dd88417428e55c82dac1ab7c028b3
    Closes-Bug: 1741378

commit 582460ecf9d503c10fd73c055301634b0b009dbc
Author: Alistair Coles <email address hidden>
Date:   Fri Jan 5 14:43:12 2018 +0000

    Document that x-delete-after takes precedence over x-delete-at
    
    Change-Id: Ib2483444d3999e13ba83ca2edd3a8ef8e5c48548

commit 31c294de797be30f499750ccbed3ec18a717f9b1
Author: Samuel Merritt <email address hidden>
Date:   Thu Jan 4 20:28:28 2018 -0800

    Fix time skew when using X-Delete-After
    
    When a client sent "X-Delete-After: <n>", the proxy and all object
    servers would each compute X-Delete-At as "int(time.time() +
    n)". However, since they don't all compute it at exactly the same
    time, the objects stored on disk can end up with differing values for
    X-Delete-At, and in that case, the object-expirer queue has multiple
    entries for the same object (one for each distinct X-Delete-At value).
    
    This commit makes two changes, either one of which is sufficient to
    fix the bug.
    
    First, after computing X-Delete-At from X-Delete-After, X-Delete-After
    is removed from the request's headers. Thus, the proxy computes
    X-Delete-At, and the object servers don't, so there's only a single
    value.
    
    Second, computation of X-Delete-At now uses the request's X-Timestamp
    instead of time.time(). In the proxy, these values are essentially the
    same; the proxy is responsible for setting X-Timestamp. In the object
    server, this ensures that all computed X-Delete-At values are
    identical, even if the object servers' clocks are not, or if one
    object server takes an extra second to respond to a PUT request.
    
    Co-Authored-By: Alistair Coles <email address hidden>
    Change-Id: I9a1b6826c4c553f0442cfe2bb78cdf49508fa4a5
    Closes-Bug: 1741371

commit a13e0ee76b1b5e56096878930fd24c638148155f
Author: Samuel Merritt <email address hidden>
Date:   Thu Jan 4 20:40:11 2018 -0800

    Ignore directory .stestr
    
    After running the functional tests, this directory shows up. I don't
    know what's in it, but I'm fairly certain I don't want to commit it.
    
    Change-Id: If9179330c337daf2ae0a01e6c8aa8d349969e737

commit 49de7db532ffaba9fbd3c7e912e007b9d8a36d7c
Author: Clay Gerrard <email address hidden>
Date:   Fri Dec 29 08:53:21 2017 -0800

    add swift-ring-builder option to recalculate dispersion
    
    Since dispersion info is cached, this can easily happen if we make
    changes to how dispersion info is calculated or stored (e.g. we extend
    the dispersion calculation to consider dispersion of all part-replicas
    in the related change)
    
    Related-Change-Id: Ifefff0260deac0c3e8b369a1e158686c89936686
    
    Change-Id: I714deb9e349cd114a21ec591216a9496aaf9e0d1

commit 9189f51d7601254181b2458f8c3e64c74d6dfad0
Author: Clay Gerrard <email address hidden>
Date:   Wed Dec 27 12:10:57 2017 -0800

    Display more info on empty rings
    
    Related-Bug: #1737068
    Related-Change-Id: Ibadaf64748728a47a8f3f861ec1af601dbfeb9e0
    Change-Id: I683677f33764fa56dadfb7f6208f7f6ee25c8557

commit 56126b28392986636e99f47c3003ed6058b62fd9
Author: vxlinux <email address hidden>
Date:   Fri Dec 22 11:40:40 2017 +0800

    Handle EmptyRingError in swift-ring-builder's default command
    
    When the default display command for swift-ring-error encounters a
    EmptyRingError trying to calculate balance it should not raise exception
    and display the traceback in a command line environment.
    
    Instead handle the exceptional condition and provide the user with
    useful feedback.
    
    Closes-Bug: #1737068
    Change-Id: Ibadaf64748728a47a8f3f861ec1af601dbfeb9e0

commit f709eed41b9579cf5a8ca9180143301a2b452d47
Author: Samuel Merritt <email address hidden>
Date:   Thu Dec 28 14:56:08 2017 -0800

    Fix socket leak on 416 EC GET responses.
    
    Sometimes, when handling an EC GET request with a Range header, the
    object servers reply 206 to the proxy, but the proxy (correctly)
    replies 416 to the client[1]. In that case, the connections to the object
    servers were not being closed. This was due to improper error handling
    in ECAppIter.
    
    Since ECAppIter is intended to be a WSGI iterable, it expects to have
    its close() method called when the caller is done with it. In this
    particular case, the caller (ECAppIter.kickoff()) was not calling
    close() when an exception was raised. Now it is.
    
    [1] consider a 4+2 EC policy with segment size 1024, an 20 byte
    object, and a request with "Range: bytes=21-50". The proxy needs whole
    fragments to decode, so it asks the object server for "Range:
    bytes=0-255" [2], the object server says 206, and then the proxy
    realizes that the client's request is unsatisfiable and tells the
    client 416.
    
    [2] segment size 1024 and 4 data fragments means the fragments have
    size 1024 / 4 = 256, hence "bytes=0-255" asks for the first whole
    fragment
    
    Change-Id: Ide2edf8c449c97d45f48c2dbbbff7aebefa4b158
    Closes-Bug: 1738804

commit 7013e70ca67891e94664e9eca70925b61ee8f689
Author: Clay Gerrard <email address hidden>
Date:   Thu Dec 14 20:03:24 2017 -0800

    Represent dispersion worse than one replicanth
    
    With a sufficiently undispersed ring it's possible to move an entire
    replicas worth of parts and yet the value of dispersion may not get any
    better (even though in reality dispersion has dramatically improved).
    The problem is dispersion will currently only represent up to one whole
    replica worth of parts being undispersed.
    
    However with EC rings it's possible for more than one whole replicas
    worth of partitions to be undispersed, in these cases the builder will
    require multiple rebalance operations to fully disperse replicas - but
    the dispersion value should improve with every rebalance.
    
    N.B. with this change it's possible for rings with a bad dispersion
    value to measure as having a significantly smaller dispersion value
    after a rebalance (even though they may not have had their dispersion
    change) because the total amount of bad dispersion we can measure has
    been increased but we're normalizing within a similar range.
    
    Closes-Bug: #1697543
    
    Change-Id: Ifefff0260deac0c3e8b369a1e158686c89936686

commit 1449532fb82b4fe3a5484b547d425dcda82df259
Author: Kazuhiro MIYAHARA <email address hidden>
Date:   Mon Dec 25 07:09:49 2017 +0000

    Allow InternalClient to container/object listing with prefix
    
    This patch adds 'prefix' argument to iter_containers/iter_objects
    method of InternalClient.
    This change will be used in general task queue feature [1].
    
    [1]: https://review.openstack.org/#/c/517389/
    
    Change-Id: I8c2067c07fe35681fdc9403da771f451c21136d3

commit 2f2899eb1df57c3ef0498c4a0d3295863a1bf798
Author: Samuel Merritt <email address hidden>
Date:   Thu Dec 14 14:57:48 2017 -0800

    Show missing branches in coverage report.
    
    This used to be the default in coverage 3.x, but 4.0+ requires you to
    explicitly configure it.
    
    Change-Id: I3b06154c7862c300b5a2b3afb14cced1e8411468