SLO etag doesn't match between container listings and object GET/HEAD

[Tim Burke]

When you create, GET, or HEAD an SLO manifest, the Etag returned is, as documented, the MD5 of the concatenation of the etags of the segments. For an example, see [1].

However, the hash presented during container listings does *not* match. Neither does it correspond to anything that the client sent nor (due to the unpredictability of dictionary iteration) anything that the client could reasonably generate. Instead, it corresponds to the MD5 of the JSON manifest that the SLO middleware generated during PUT [2].

When SLO was originally written, it *had* to be this way; there was no way to specify a container listing override. With EC support, we grew X-Backend-Container-Update-Override-* headers [3], though that namespace still had consistency issues, specifically if a POST update arrived before the PUT update [4]. With encryption support, we grew X-Object-Sysmeta-Container-Update-Override-* headers [5], and we finally have a way that we could fix this properly for new SLOs.

(Note that there's no good way to fix this for existing SLOs; we've got data on disk, the container updates have already been sent, etc.)

[1] http://paste.openstack.org/show/564868/
[2] http://paste.openstack.org/show/564870/
[3] https://review.openstack.org/#/c/158821/
[4] https://bugs.launchpad.net/swift/+bug/1582723
[5] https://review.openstack.org/#/c/328205/

[clayg (clay-gerrard)]

so the ETag in the listing is the ETag you see with ?multipart-manifest=get [1]

I like that it's consistent anyway...

1. https://gist.github.com/clayg/f062910ac72ad5120c5ac49d28f73fa7

[Tim Burke (1-tim-z)]

Bonus advantage -- when uploading the same large object with the same segment size via swiftclient, you'll get different listing etags if the local mtime changed, despite the fact that the etag on GET would be the same. Forcing the listing etag to match the GET etag fixes that.

There are similar re-upload issues with swift3, because of randomized upload IDs that get baked into the segment paths.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/337960
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=c4c98eb64d3d99a5fb58f0390600f3e7755da1b2
Submitter: Zuul
Branch: master

commit c4c98eb64d3d99a5fb58f0390600f3e7755da1b2
Author: Tim Burke <email address hidden>
Date: Fri May 20 13:17:16 2016 -0700

    Include SLO ETag in container updates

    Container servers will store an etag like

       <MD5 of manifest on disk>; slo_etag=<MD5 on concatenated ETags>

    which the SLO middleware will break out into separate

       "hash": "<MD5 of manifest on disk",
       "slo_etag": "\"<MD5 of concatenated ETags\"",

    keys for JSON listings. Text and XML listings are unaffected.

    If a middleware left of SLO already specified a container update
    override, the slo_etag parameter will be appended. If the base header
    value was blank, the MD5 of the manifest will be inserted.

    SLOs that were created on previous versions of Swift will continue to
    just have the MD5 of the manifest in container listings.

    Closes-Bug: 1618573
    Change-Id: I67478923619b00ec1a37d56b6fec6a218453dafc

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.19.0 release.