From 736de613f1e2a6a460f4499cbd1e9f7f1fc3da68 Mon Sep 17 00:00:00 2001
From: Alistair Coles <alistair.coles@hpe.com>
Date: Tue, 22 Mar 2016 11:36:32 +0000
Subject: [PATCH] Docs: Container sync does not require POST-as-COPY

Updates docs to remove warnings that container sync only
works with object_post_as_copy=True. Since commit e91de49
container sync will also sync POST updates when using
object_post_as_copy=False.

Change-Id: I5cc3cc6e8f9ba2fef6f896f2b11d2a4e06825f7f
---
 doc/manpages/proxy-server.conf.5       |  3 +--
 doc/source/deployment_guide.rst        |  6 +-----
 doc/source/overview_container_sync.rst | 14 --------------
 etc/proxy-server.conf-sample           |  3 +--
 swift/container/sync.py                |  7 -------
 5 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/doc/manpages/proxy-server.conf.5 b/doc/manpages/proxy-server.conf.5
index 724aafd70c..6fd9d16ea3 100644
--- a/doc/manpages/proxy-server.conf.5
+++ b/doc/manpages/proxy-server.conf.5
@@ -971,8 +971,7 @@ is false.
 .IP \fBobject_post_as_copy\fR
 Set object_post_as_copy = false to turn on fast posts where only the metadata changes
 are stored as new and the original data file is kept in place. This makes for quicker
-posts; but since the container metadata isn't updated in this mode, features like
-container sync won't be able to sync posts. The default is True.
+posts. The default is True.
 .IP \fBaccount_autocreate\fR
 If set to 'true' authorized accounts that do not yet exist within the Swift cluster
 will be automatically created. The default is set to false.
diff --git a/doc/source/deployment_guide.rst b/doc/source/deployment_guide.rst
index 94d418c660..590b1f6a27 100644
--- a/doc/source/deployment_guide.rst
+++ b/doc/source/deployment_guide.rst
@@ -1325,11 +1325,7 @@ object_post_as_copy           true             Set object_post_as_copy = false
                                                the metadata changes are stored
                                                anew and the original data file
                                                is kept in place. This makes for
-                                               quicker posts; but since the
-                                               container metadata isn't updated
-                                               in this mode, features like
-                                               container sync won't be able to
-                                               sync posts.
+                                               quicker posts.
 account_autocreate            false            If set to 'true' authorized
                                                accounts that do not yet exist
                                                within the Swift cluster will
diff --git a/doc/source/overview_container_sync.rst b/doc/source/overview_container_sync.rst
index c1255acaff..25772bdf1e 100644
--- a/doc/source/overview_container_sync.rst
+++ b/doc/source/overview_container_sync.rst
@@ -12,13 +12,6 @@ configure their cluster to allow/accept sync requests to/from other clusters,
 and the user specifies where to sync their container to along with a secret
 synchronization key.
 
-.. note::
-
-    Container sync will sync object POSTs only if the proxy server is set to
-    use "object_post_as_copy = true" which is the default. So-called fast
-    object posts, "object_post_as_copy = false" do not update the container
-    listings and therefore can't be detected for synchronization.
-
 .. note::
 
     If you are using the large objects feature you will need to ensure both
@@ -386,13 +379,6 @@ from ``sync-containers``.
     cluster. Therefore, the container servers must be permitted to initiate
     outbound connections to the remote proxy servers (or load balancers).
 
-.. note::
-
-    Container sync will sync object POSTs only if the proxy server is set to
-    use "object_post_as_copy = true" which is the default. So-called fast
-    object posts, "object_post_as_copy = false" do not update the container
-    listings and therefore can't be detected for synchronization.
-
 The actual syncing is slightly more complicated to make use of the three
 (or number-of-replicas) main nodes for a container without each trying to
 do the exact same work but also without missing work if one node happens to
diff --git a/etc/proxy-server.conf-sample b/etc/proxy-server.conf-sample
index 8267ce4ab6..a746329b55 100644
--- a/etc/proxy-server.conf-sample
+++ b/etc/proxy-server.conf-sample
@@ -131,8 +131,7 @@ use = egg:swift#proxy
 #
 # Set object_post_as_copy = false to turn on fast posts where only the metadata
 # changes are stored anew and the original data file is kept in place. This
-# makes for quicker posts; but since the container metadata isn't updated in
-# this mode, features like container sync won't be able to sync posts.
+# makes for quicker posts.
 # object_post_as_copy = true
 #
 # If set to 'true' authorized accounts that do not yet exist within the Swift
diff --git a/swift/container/sync.py b/swift/container/sync.py
index 7bb37f9225..0b3b933ac7 100644
--- a/swift/container/sync.py
+++ b/swift/container/sync.py
@@ -100,13 +100,6 @@ class ContainerSync(Daemon):
     If they exist, newer rows since the last sync will trigger PUTs or DELETEs
     to the other container.
 
-    .. note::
-
-        Container sync will sync object POSTs only if the proxy server is set
-        to use "object_post_as_copy = true" which is the default. So-called
-        fast object posts, "object_post_as_copy = false" do not update the
-        container listings and therefore can't be detected for synchronization.
-
     The actual syncing is slightly more complicated to make use of the three
     (or number-of-replicas) main nodes for a container without each trying to
     do the exact same work but also without missing work if one node happens to