Make container sync copy SLO manifests

Currently the container sync daemon fails to copy
an SLO manifest, and the error will stall progress
of the sync process on that container. There are
several reasons why the sync of an SLO manifest
may fail:

1. The GET of the manifest from the source
   container returns an X-Static-Large-Object header
   that is not allowed to be included with a PUT
   to the destination container.

2. The format of the manifest object that is read
   from the source is not in the syntax required
   for a SLO manifest PUT.

3. Assuming 2 were fixed, the PUT of the manifest
   includes an ETag header which will not match the
   md5 of the manifest generated by the receiving
   proxy's SLO middleware.

4. If the manifest is being synced to a different
   account and/or cluster, then the SLO segments may
   not have been synced and so the validation of the
   PUT manifest will fail.

This patch addresses all of these obstacles by
enabling the destination container-sync middleware to
cause the SLO middleware to be bypassed by setting a
swift.slo_override flag in the request environ. This
flag is only set for request that have been validated
as originating from a container sync peer.

This is justifed by noting that a SLO manifest PUT from
a container sync peer can be assumed to have valid syntax
because it was already been validated when written to
the source container.

Furthermore, we must allow SLO manifests to be synced
without requiring the semantic of their content to be
re-validated because we have no way to enforce or check
that segments have been synced prior to the manifest, nor
to check that the semantic of the manifest is still valid
at the source.

This does mean that GETs to synced SLO manifests may fail
if segments have not been synced. This is however
consistent with the expectation for synced DLO manifests
and indeed for the source SLO manifest if segments have
been deleted since it was written.

Co-Authored-By: Oshrit Feder <oshritf@il.ibm.com>
Change-Id: I8d503419b7996721a671ed6b2795224775a7d8c6
Closes-Bug: #1605597

1 files changed, 18 insertions, 7 deletions

diff --git a/doc/source/overview_container_sync.rst b/doc/source/overview_container_sync.rst
index 0fb24f50d..743e2cc12 100644
--- a/doc/source/overview_container_sync.rst
+++ b/doc/source/overview_container_sync.rst
@@ -14,13 +14,24 @@ synchronization key.
 
 .. note::
 
-    If you are using the large objects feature and syncing to another cluster
-    then you will need to ensure that manifest files and segment files are
-    synced. If segment files are in a different container than their manifest
-    then both the manifest's container and the segments' container must be
-    synced. The target container for synced segment files must always have the
-    same name as their source container in order for them to be resolved by
-    synced manifests.
+    If you are using the :ref:`Large Objects <large-objects>` feature and
+    syncing to another cluster then you will need to ensure that manifest files
+    and segment files are synced. If segment files are in a different container
+    than their manifest then both the manifest's container and the segments'
+    container must be synced. The target container for synced segment files
+    must always have the same name as their source container in order for them
+    to be resolved by synced manifests.
+
+    Be aware that manifest files may be synced before segment files even if
+    they are in the same container and were created after the segment files.
+
+    In the case of :ref:`Static Large Objects <static-large-objects>`, a GET
+    request for a manifest whose segments have yet to be completely synced will
+    fail with none or only part of the large object content being returned.
+
+    In the case of :ref:`Dynamic Large Objects <dynamic-large-objects>`, a GET
+    request for a manifest whose segments have yet to be completely synced will
+    either fail or return unexpected (and most likely incorrect) content.
 
 .. note::