post-as-copy or COPY of SLO manifest results in wrong content-type in container listing

Bug #1583756 reported by Alistair Coles
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released
Undecided
Alistair Coles

Bug Description

When an SLO manifest is PUT with a content-type=foo, the container listing for the manifest will have content-type=foo and HEAD on the manifest will also return content-type=foo.

When an SLO manifest is copied using multipart-manifest=get, or posted to with object_post_as_copy=True (default), the content-type that is written to the destination manifest is always "application/json; charset=utf-8" which is a value synthesised by SLO for manifest GETs. The container listing for that manifest, or a HEAD on that manifest, will return content-type "application/json; charset=utf-8".

COPY (and post-as-copy) sets the multipart-manifest=get param format=raw - this should cause SLO to return the "raw" content-type and not "application/json; charset=utf-8".

Revision history for this message
Alistair Coles (alistair-coles) wrote :

This is related to but different from https://bugs.launchpad.net/swift/+bug/1260446

Changed in swift:
assignee: nobody → Alistair Coles (alistair-coles)
Revision history for this message
Alistair Coles (alistair-coles) wrote :

https://bugs.launchpad.net/swift/+bug/1260446 is actually fixed by copy middleware, commit 46d61a4

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master)

Fix proposed to branch: master
Review: https://review.openstack.org/318891

Changed in swift:
status: New → In Progress
tags: added: slo
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

Reviewed: https://review.openstack.org/318891
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=d0ec1adb78b26f5c24312090796c69912e9e3da9
Submitter: Jenkins
Branch: master

commit d0ec1adb78b26f5c24312090796c69912e9e3da9
Author: Alistair Coles <email address hidden>
Date: Thu May 19 19:58:56 2016 +0100

    Make SLO manifest copies retain correct content-type

    When copying an SLO manifest with multipart-manifest=get the actual
    manifest content-type should get copied to the destination, rather
    than the application/json value that is synthesised by SLO in a GET
    response. That way the result of a HEAD on the copied manifest is the
    same as a HEAD to the source, and the container listings for the two
    are consistent.

    This patch also un-skips a functional test and adds functional tests
    that verify this patch and also verify that etags and size also get
    correctly copied and updated in destination container (bug #1260446).

    Closes-Bug: #1260446
    Closes-Bug: #1583756

    Change-Id: Ie7fa82f70b3ec3ef568f5355c69f6bce460ba25d

Changed in swift:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/hummingbird)

Fix proposed to branch: feature/hummingbird
Review: https://review.openstack.org/323599

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/hummingbird)
Download full text (84.7 KiB)

Reviewed: https://review.openstack.org/323599
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=0330478b70d0a699a0f9c21ef87c7e639d92564b
Submitter: Jenkins
Branch: feature/hummingbird

commit 5fe392b562de3baed080704df433fb392cb4fb31
Author: Ondřej Nový <email address hidden>
Date: Tue May 31 16:25:50 2016 +0200

    Fixed typo

    Change-Id: I7a35c0076360c7a23cf405189828d3c252ec6708

commit b52eccb3b1ea0591f0040587228d3705b5d3f68d
Author: Clay Gerrard <email address hidden>
Date: Wed May 25 11:21:25 2016 -0700

    Clarify overload best practices in admin guide

    Change-Id: Ib7c08bdeab6374771bb8e2b05053e7e16973524d

commit f1fd50723bb84c4941e949895576733f6eb67793
Author: Christian Schwede <email address hidden>
Date: Wed May 25 09:53:31 2016 +0200

    Add dispersion --verbose example to admin guide

    Change-Id: I5f9cacedde2a329332ccf744800b6f2453e8b28e

commit b3ab715c055283ccfea9a504d6da20741d82e7ad
Author: Matthew Oliver <email address hidden>
Date: Wed May 25 14:35:54 2016 +1000

    Add ring-builder dispersion command to admin guide

    This change updates the admin guide to point out the dispersion command
    in swift-ring-builder and mentions the dispersion verbose table to make
    it more obvious to operators.

    Change-Id: I72b4c8b2d718e6063de0fdabbaf4f2b73694e0a4

commit fb7a8e9ab7596a36a6992a3a8f8c6d005a2c2829
Author: Tim Burke <email address hidden>
Date: Tue May 24 13:37:58 2016 -0700

    Add links to mitaka install guides

    Change-Id: I62331923751c521daded4468b5cc5f03655226bc

commit e09c4ee7800e82aa09ca2f6ae375420b766182a4
Author: Tim Burke <email address hidden>
Date: Fri Apr 29 12:12:00 2016 -0500

    Allow concurrent bulk deletes

    Before, server-side deletes of static large objects could take a long
    time to complete since the proxy would wait for a response to each
    segment DELETE before starting the next DELETE request.

    Now, operators can configure a concurrency factor for the slo and bulk
    middlewares to allow up to N concurrent DELETE requests. By default, two
    DELETE requests will be allowed at a time.

    Note that objects and containers are now deleted in separate passes, to
    reduce the likelihood of 409 Conflict responses when deleting
    containers.

    Upgrade Consideration
    =====================
    If operators have enabled the bulk or slo middlewares and would like to
    preserve the prior (single-threaded) DELETE behavior, they must add the
    following line to their [filter:slo] and [filter:bulk] proxy config
    sections:

       delete_concurrency = 1

    This may be done prior to upgrading Swift.

    UpgradeImpact
    Closes-Bug: 1524454
    Change-Id: I128374d74a4cef7a479b221fd15eec785cc4694a

commit 226557afc42c245e050d84162497f46341407ef7
Author: Tim Burke <email address hidden>
Date: Thu May 19 18:55:40 2016 -0700

    Turn on H703, so our translators don't punch us

    Change-Id: I4ce3068f79563e4d4296c6e1078bc12f0cf84c96
    Related-Bug: 1559431

commit 7b706926a8ed5bbcec3a678e868e301c9a6ed8f1
Author: Alistair Coles <email address hidden>
Date: Mon May ...

tags: added: in-feature-hummingbird
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/crypto)

Fix proposed to branch: feature/crypto
Review: https://review.openstack.org/323875

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/crypto)
Download full text (4.8 KiB)

Reviewed: https://review.openstack.org/323875
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=03b8b4bfa9e28076ece78f131c95655b38b89971
Submitter: Jenkins
Branch: feature/crypto

commit 86e9e827bab7bedb529a467f217eb17b3b7e0967
Author: John Dickinson <email address hidden>
Date: Tue May 31 11:27:43 2016 -0700

    add explicit HA info to the deployment guide

    Change-Id: I7614952c523080fe50eaf839b54a8064439817ce

commit 5fe392b562de3baed080704df433fb392cb4fb31
Author: Ondřej Nový <email address hidden>
Date: Tue May 31 16:25:50 2016 +0200

    Fixed typo

    Change-Id: I7a35c0076360c7a23cf405189828d3c252ec6708

commit a821dd42de1762e61a26ec9cac90976a9cd4e51f
Author: Tim Burke <email address hidden>
Date: Thu May 26 13:42:12 2016 -0700

    Don't include holes when reporting how many devices a ring has

    Change-Id: I9b933051aec009c6108ee9d2dd5c0978772bf699

commit b52eccb3b1ea0591f0040587228d3705b5d3f68d
Author: Clay Gerrard <email address hidden>
Date: Wed May 25 11:21:25 2016 -0700

    Clarify overload best practices in admin guide

    Change-Id: Ib7c08bdeab6374771bb8e2b05053e7e16973524d

commit f1fd50723bb84c4941e949895576733f6eb67793
Author: Christian Schwede <email address hidden>
Date: Wed May 25 09:53:31 2016 +0200

    Add dispersion --verbose example to admin guide

    Change-Id: I5f9cacedde2a329332ccf744800b6f2453e8b28e

commit b3ab715c055283ccfea9a504d6da20741d82e7ad
Author: Matthew Oliver <email address hidden>
Date: Wed May 25 14:35:54 2016 +1000

    Add ring-builder dispersion command to admin guide

    This change updates the admin guide to point out the dispersion command
    in swift-ring-builder and mentions the dispersion verbose table to make
    it more obvious to operators.

    Change-Id: I72b4c8b2d718e6063de0fdabbaf4f2b73694e0a4

commit fb7a8e9ab7596a36a6992a3a8f8c6d005a2c2829
Author: Tim Burke <email address hidden>
Date: Tue May 24 13:37:58 2016 -0700

    Add links to mitaka install guides

    Change-Id: I62331923751c521daded4468b5cc5f03655226bc

commit e09c4ee7800e82aa09ca2f6ae375420b766182a4
Author: Tim Burke <email address hidden>
Date: Fri Apr 29 12:12:00 2016 -0500

    Allow concurrent bulk deletes

    Before, server-side deletes of static large objects could take a long
    time to complete since the proxy would wait for a response to each
    segment DELETE before starting the next DELETE request.

    Now, operators can configure a concurrency factor for the slo and bulk
    middlewares to allow up to N concurrent DELETE requests. By default, two
    DELETE requests will be allowed at a time.

    Note that objects and containers are now deleted in separate passes, to
    reduce the likelihood of 409 Conflict responses when deleting
    containers.

    Upgrade Consideration
    =====================
    If operators have enabled the bulk or slo middlewares and would like to
    preserve the prior (single-threaded) DELETE behavior, they must add the
    following line to their [filter:slo] and [filter:bulk] proxy config
    sections:

       delete_concurrency = 1

    This may be done prior to upgrading Swif...

Read more...

tags: added: in-feature-crypto
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/swift 2.8.0

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.