ssync doesn't sync X-Static-Large-Object

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

Bug Description

if you upload a static large object:

https://gist.github.com/clayg/ae43968b46022ef79235

Then delete some of the .data files and run ssync (object-replicator)

Some of the newly replicated .data files don't have the X-Static-Large-Object metadata set (maybe some other metadata as well?)

Tags: ssync
Revision history for this message
clayg (clay-gerrard) wrote :
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

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

commit 7c1c8c0b4d36ec1795c11950652fa42564352264
Author: David Goetz <email address hidden>
Date: Tue Oct 7 15:25:59 2014 -0700

    Ssync does not replicate custom object headers

    Closes-Bug: #1329093

    Change-Id: Ie9d80089a38d7a9b3464c66237d4d2d23331ebd5

Changed in swift:
status: New → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/ec)

Fix proposed to branch: feature/ec
Review: https://review.openstack.org/133750

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

Reviewed: https://review.openstack.org/133750
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=01b77740103e0dbe69b1d25ac6bd51f12310cae6
Submitter: Jenkins
Branch: feature/ec

commit fdcd20f2b6496a9e857cb47ae8907938033be9df
Author: John Dickinson <email address hidden>
Date: Fri Nov 7 10:34:51 2014 +0100

    added docs on specs workflow to CONTRIBUTING.md

    Change-Id: Id83d1da2a7a594a07fc5332b918539b3728e101b

commit ecc946b4ffb09ca0a94998ef54a7af7d4c572aff
Author: Christian Schwede <email address hidden>
Date: Thu Nov 6 15:44:29 2014 +0100

    Rename Swiftbrowser in associated projects

    Let's use the full project name to avoid confusion with the recently added
    Swiftbrowser based on AngularJS.

    Change-Id: Ib07338268a1593bc2882908b49c1fb4a130ff43d

commit dff981a03eac34a4c776cfd9a1528f1c3824f29b
Author: Martin Geisler <email address hidden>
Date: Thu Nov 6 14:52:04 2014 +0100

    Add Swift Browser as an associated project

    This is a JavaScript based browser for Swift.

    Change-Id: I2e304d4a0623c715f8712a358fef5067abc8935b

commit f9bed74d1bba6a512becd057c3139c54c176c226
Author: Clay Gerrard <email address hidden>
Date: Wed Oct 29 15:59:45 2014 -0700

    Return 403 on unauthorized upload when over account quota

    If you try an unauthorized upload into a container that is over quota you get
    a 403 instead of a 413, but if you try to unauthorized upload when an
    *account* is over quota you can see the 413 even though the upload would have
    been rejected by the authorize callback. By wrapping the authorize callback
    associated with the incoming request we can make sure to only return our 413
    when the request would have been authorized otherwise.

    Drive by doc fixes thanks to acoles:

     * State that container_quotas should be after auth middleware in
       the class doc string.
     * Add note to proxy-server.conf.sample that account_quotas should
       be after auth middleware.

    The equivalent statements are already in place for each quota
    middleware.

    Doc-Impact

    Closes-Bug: #1387415
    Change-Id: I2a88b3ec79d35bfdd73ea6ad64e376b7c7af4ea6

commit cbc52a7a4ea32f7d84f54948aa9ebb5decd26813
Author: Christian Schwede <email address hidden>
Date: Thu Oct 23 16:23:20 2014 +0200

    Return verbose message if account quota exceeded

    This message is already used in the container quota middleware, so let's use it
    in the account middleware too.

    Change-Id: I136fe6102c28cc8ccc021555c42ec7b0be716444
    Closes-Bug: 1381875

commit 83030b921dd83a84a2e966c88156e64d30fb9c24
Author: Christian Schwede <email address hidden>
Date: Wed Oct 29 10:34:53 2014 +0000

    Update admin guide on handling drive failures

    Simply replacing a failed disk requires a very long time if the ring is not
    changed, because all data will be replicated to a single new disk. This extends
    the time to recover from missing replicas, and becomes even more important with
    bigger disks.

    This patch updates the doc to include a faster alternative by setting the weight
    of a fail...

Read more...

Thierry Carrez (ttx)
Changed in swift:
milestone: none → 2.2.1
status: Fix Committed → Fix Released
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.