Backup to swift using wrong large object type

[Matthew Van Dijk]

Backup to Swift should use Static Large Objects instead of the current Dynamic Large Objects.
A problem with DLO is that it relies on eventual consistency of container listing. This means that a restore could pull down an incomplete object.
SLO does not rely on eventual consistency. It can also provides significantly improved download performance.

[Craig Vyvial (cp16net)]

I just had deja'vu when I read this bug.

[OpenStack Infra (hudson-openstack)]

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

[Nikhil Manchanda (slicknik)]

Not an RC1 blocker.

[Amrith Kumar (amrith)]

Matt, the patch for this is in need of TLC.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/222752
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=6672fe868a5e98de308ec884b753878afb4a475b
Submitter: Jenkins
Branch: master

commit 6672fe868a5e98de308ec884b753878afb4a475b
Author: Matt Van Dijk <email address hidden>
Date: Fri Sep 11 15:55:30 2015 -0400

    Backup to swift using wrong large object type

    Trove backups are stored in Swift as Dynamic Large Objects. This is not
    ideal, and could cause restore to fail as DLOs may not return all of
    their parts. Static Large Objects should be used instead. SLOs perform
    checksum and object size validation and can reduce object download times
    significantly.

    Changes are needed to the Swift storage strategy and taskmanager's
    backup delete model to perform actions on SLOs. The corresponding
    unittests and fakes are also updated.

    A special case occurs when the backup object fits in a single Swift
    object segment, in which case it will not be made a SLO.

    Change-Id: Ide30a1e7f909a3b7fecb16268367b56468306d42
    Closes-bug: 1489997

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/trove 6.0.0.0b2 development milestone.