openstack/swift
Code Issues Proposed changes

Docs: Container sync does not require POST-as-COPY

Browse Source 
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
This commit is contained in:
Alistair Coles 2016-03-22 11:36:32 +00:00
parent 7cc2c783a4
commit 736de613f1
5 changed files with 3 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/manpages/proxy-server.conf.5
View File

@ -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.

6
doc/source/deployment_guide.rst
View File

@ -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

14
doc/source/overview_container_sync.rst
View File

@ -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

3
etc/proxy-server.conf-sample
View File

@ -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

7
swift/container/sync.py
View File

@ -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