swift.conf - common configuration file for the OpenStack
    object storage services
This is the common configuration file used by all services of
    OpenStack object storage services.
The configuration file follows the python-pastedeploy syntax. The
    file is divided into sections, which are enclosed by square brackets. Each
    section will contain a certain number of key/value parameters which are
    described later.
Any line that begins with a '#' symbol is ignored.
You can find more information about python-pastedeploy
    configuration format at
  http://pythonpaste.org/deploy/#config-format
This is indicated by section named [swift-hash]. Below
  are the parameters that are acceptable within this section:
  - swift_hash_path_suffix
 
  
  - swift_hash_path_prefix
 
  - 
    
swift_hash_path_suffix and swift_hash_path_prefix are used as
        part of 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)").
    
    
    
   
 
This is indicated by section name [storage-policy:#]
Storage policies are defined here and they determine various
    characteristics about how objects are stored and treated. Policies are
    specified by name on a per container basis. 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 mandatory when defining a storage policy.
  - [storage-policy:index]
 
  - Each storage policy is defined in a separate section with an index
      specified in the header. Below are the parameters that are acceptable
      within this section:
    
  
 
  - name
 
  - Name of the storage policy. Policy names are case insensitive.
 
  - aliases
 
  - Multiple names can be assigned to one policy using aliases. All names must
      follow the Swift naming rules.
 
  - policy_type
 
  - Policy type can be replication or erasure_coding. Replication policy
      replicates the objects to specified number of replicas. Erasure coding
      uses PyECLib API library for encode/decode operations. Please refer to
      Swift documentation for details on how erasure coding is implemented.
 
  - ec_type
 
  - This parameter must be chosen from the list of EC backends supported by
      PyECLib.
 
  - ec_num_data_fragments
 
  - This parameter is specific to 'erasure coding' policy_type only. It
      defines the number of fragments that will be comprised of data.
 
  - ec_num_parity_fragments
 
  - This parameter is specific to 'erasure coding' policy_type only. It
      defines the number of fragments that will be comprised of parity.
 
  - ec_object_segment_size
 
  - This parameter is specific to 'erasure coding' policy_type only. It
      defines the amount of data that will be buffered up before feeding a
      segment into the encoder/decoder. The default value is 1048576.
 
  - Examples:
 
  - 
    
  
 
  - [storage-policy:0]
 
  
  - name = Policy-0
 
  
  - default = yes
 
  
  - policy_type
    = replication
 
  
  - aliases = yellow,
    orange
 
  - 
    
  
 
  - [storage-policy:1]
 
  
  - name = silver
 
  
  - policy_type
    = replication
 
  - 
    
  
 
  - [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
 
  
 
This is indicated by section name [swift-constraints].
  This 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. Below are the parameters that are acceptable within this
  section:
  - max_file_size
 
  - 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_meta_name_length
 
  - max_meta_name_length is the max number of bytes in the utf8 encoding of
      the name portion of a metadata header.
 
  - max_meta_value_length
 
  - max_meta_value_length is the max number of bytes in the utf8 encoding of a
      metadata value.
 
  - max_meta_count
 
  - max_meta_count is the max number of metadata keys that can be stored on a
      single account, container, or object.
 
  - max_meta_overall_size
 
  - max_meta_overall_size is the max number of bytes in the utf8 encoding of
      the metadata (keys + values).
 
  
  - max_header_size is the max number of bytes in the utf8 encoding of each
      header. Using 8192 as default because eventlet uses 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.
 
  
  - By default the maximum number of allowed headers depends on the number of
      max allowed metadata settings plus a default value of 36 for swift
      internally generated headers and 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.
 
  - max_object_name_length
 
  - max_object_name_length is the max number of bytes in the utf8 encoding of
      an object name.
 
  - container_listing_limit
 
  - container_listing_limit is the default (and max) number of items returned
      for a container listing request.
 
  - account_listing_limit
 
  - account_listing_limit is the default (and max) number of items returned
      for an account listing request.
 
  - max_account_name_length
 
  - max_account_name_length is the max number of bytes in the utf8 encoding of
      an account name.
 
  - max_container_name_length
 
  - max_container_name_length is the max number of bytes in the utf8 encoding
      of a container name.
 
  - valid_api_versions
 
  - 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.
 
  - auto_create_account_prefix
 
  - auto_create_account_prefix specifies the prefix for system accounts, such
      as those used by the object-expirer, and container-sharder. Default is
      ".".
    
    
    
  
 
 
More in depth documentation about the swift.conf and also
    OpenStack-Swift as a whole can be found at
    https://docs.openstack.org/swift/latest/admin_guide.html and
    https://docs.openstack.org/swift/latest/