1 files changed, 183 insertions, 0 deletions
diff --git a/deploy/adapters/ansible/roles/swift/templates/swift.conf b/deploy/adapters/ansible/roles/swift/templates/swift.conf
new file mode 100644
index 00000000..9a31501b
--- /dev/null
+++ b/deploy/adapters/ansible/roles/swift/templates/swift.conf
@@ -0,0 +1,183 @@
+[swift-hash]
+
+# swift_hash_path_suffix and swift_hash_path_prefix are used as part of the
+# the hashing algorithm when determining data placement in the cluster.
+# These values should remain secret and MUST NOT change
+# once a cluster has been deployed.
+# Use only printable chars (python -c "import string; print(string.printable)")
+
+swift_hash_path_suffix = 7c6a7cd34d07aed5
+swift_hash_path_prefix = 0c4629166f4de441
+
+# storage policies are defined here and determine various characteristics
+# about how objects are stored and treated.  Policies are specified by name on
+# a per container basis.  Names are case-insensitive.  The policy index is
+# specified in the section header and is used internally.  The policy with
+# index 0 is always used for legacy containers and can be given a name for use
+# in metadata however the ring file name will always be 'object.ring.gz' for
+# backwards compatibility.  If no policies are defined a policy with index 0
+# will be automatically created for backwards compatibility and given the name
+# Policy-0.  A default policy is used when creating new containers when no
+# policy is specified in the request.  If no other policies are defined the
+# policy with index 0 will be declared the default.  If multiple policies are
+# defined you must define a policy with index 0 and you must specify a
+# default.  It is recommended you always define a section for
+# storage-policy:0. Aliases are not required when defining a storage policy.
+#
+# A 'policy_type' argument is also supported but is not mandatory.  Default
+# policy type 'replication' is used when 'policy_type' is unspecified.
+[storage-policy:0]
+name = Policy-0
+default = yes
+#policy_type = replication
+aliases = yellow, orange
+
+# the following section would declare a policy called 'silver', the number of
+# replicas will be determined by how the ring is built.  In this example the
+# 'silver' policy could have a lower or higher # of replicas than the
+# 'Policy-0' policy above.  The ring filename will be 'object-1.ring.gz'.  You
+# may only specify one storage policy section as the default.  If you changed
+# this section to specify 'silver' as the default, when a client created a new
+# container w/o a policy specified, it will get the 'silver' policy because
+# this config has specified it as the default.  However if a legacy container
+# (one created with a pre-policy version of swift) is accessed, it is known
+# implicitly to be assigned to the policy with index 0 as opposed to the
+# current default. Note that even without specifying any aliases, a policy
+# always has at least the default name stored in aliases because this field is
+# used to contain all human readable names for a storage policy.
+#
+#[storage-policy:1]
+#name = silver
+#policy_type = replication
+
+# The following declares a storage policy of type 'erasure_coding' which uses
+# Erasure Coding for data reliability. Please refer to Swift documentation for
+# details on how the 'erasure_coding' storage policy is implemented.
+#
+# Swift uses PyECLib, a Python Erasure coding API library, for encode/decode
+# operations.  Please refer to Swift documentation for details on how to
+# install PyECLib.
+#
+# When defining an EC policy, 'policy_type' needs to be 'erasure_coding' and
+# EC configuration parameters 'ec_type', 'ec_num_data_fragments' and
+# 'ec_num_parity_fragments' must be specified.  'ec_type' is chosen from the
+# list of EC backends supported by PyECLib.  The ring configured for the
+# storage policy must have it's "replica" count configured to
+# 'ec_num_data_fragments' + 'ec_num_parity_fragments' - this requirement is
+# validated when services start.  'ec_object_segment_size' is the amount of
+# data that will be buffered up before feeding a segment into the
+# encoder/decoder.  More information about these configuration options and
+# supported `ec_type` schemes is available in the Swift documentation.  Please
+# refer to Swift documentation for details on how to configure EC policies.
+#
+# The example 'deepfreeze10-4' policy defined below is a _sample_
+# configuration with an alias of 'df10-4' as well as 10 'data' and 4 'parity'
+# fragments. 'ec_type' defines the Erasure Coding scheme.
+# 'liberasurecode_rs_vand' (Reed-Solomon Vandermonde) is used as an example
+# below.
+#
+#[storage-policy:2]
+#name = deepfreeze10-4
+#aliases = df10-4
+#policy_type = erasure_coding
+#ec_type = liberasurecode_rs_vand
+#ec_num_data_fragments = 10
+#ec_num_parity_fragments = 4
+#ec_object_segment_size = 1048576
+
+
+# The swift-constraints section sets the basic constraints on data
+# saved in the swift cluster. These constraints are automatically
+# published by the proxy server in responses to /info requests.
+
+[swift-constraints]
+
+# max_file_size is the largest "normal" object that can be saved in
+# the cluster. This is also the limit on the size of each segment of
+# a "large" object when using the large object manifest support.
+# This value is set in bytes. Setting it to lower than 1MiB will cause
+# some tests to fail. It is STRONGLY recommended to leave this value at
+# the default (5 * 2**30 + 2).
+
+#max_file_size = 5368709122
+
+
+# max_meta_name_length is the max number of bytes in the utf8 encoding
+# of the name portion of a metadata header.
+
+#max_meta_name_length = 128
+
+
+# max_meta_value_length is the max number of bytes in the utf8 encoding
+# of a metadata value
+
+#max_meta_value_length = 256
+
+
+# max_meta_count is the max number of metadata keys that can be stored
+# on a single account, container, or object
+
+#max_meta_count = 90
+
+
+# max_meta_overall_size is the max number of bytes in the utf8 encoding
+# of the metadata (keys + values)
+
+#max_meta_overall_size = 4096
+
+# max_header_size is the max number of bytes in the utf8 encoding of each
+# header. Using 8192 as default because eventlet use 8192 as max size of
+# header line. This value may need to be increased when using identity
+# v3 API tokens including more than 7 catalog entries.
+# See also include_service_catalog in proxy-server.conf-sample
+# (documented in overview_auth.rst)
+
+#max_header_size = 8192
+
+
+# By default the maximum number of allowed headers depends on the number of max
+# allowed metadata settings plus a default value of 32 for regular http
+# headers.  If for some reason this is not enough (custom middleware for
+# example) it can be increased with the extra_header_count constraint.
+
+#extra_header_count = 0
+
+
+# max_object_name_length is the max number of bytes in the utf8 encoding
+# of an object name
+
+#max_object_name_length = 1024
+
+
+# container_listing_limit is the default (and max) number of items
+# returned for a container listing request
+
+#container_listing_limit = 10000
+
+
+# account_listing_limit is the default (and max) number of items returned
+# for an account listing request
+#account_listing_limit = 10000
+
+
+# max_account_name_length is the max number of bytes in the utf8 encoding
+# of an account name
+
+#max_account_name_length = 256
+
+
+# max_container_name_length is the max number of bytes in the utf8 encoding
+# of a container name
+
+#max_container_name_length = 256
+
+
+# By default all REST API calls should use "v1" or "v1.0" as the version string,
+# for example "/v1/account". This can be manually overridden to make this
+# backward-compatible, in case a different version string has been used before.
+# Use a comma-separated list in case of multiple allowed versions, for example
+# valid_api_versions = v0,v1,v2
+# This is only enforced for account, container and object requests. The allowed
+# api versions are by default excluded from /info.
+
+# valid_api_versions = v1,v1.0