[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 = changeme swift_hash_path_prefix = changeme # 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