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