Middleware¶

Account Quotas¶

account_quotas is a middleware which blocks write requests (PUT, POST) if a given account quota (in bytes) is exceeded while DELETE requests are still allowed.

account_quotas uses the x-account-meta-quota-bytes metadata entry to store the quota. Write requests to this metadata entry are only permitted for resellers. There is no quota limit if x-account-meta-quota-bytes is not set.

The account_quotas middleware should be added to the pipeline in your /etc/swift/proxy-server.conf file just after any auth middleware. For example:

[pipeline:main]
pipeline = catch_errors cache tempauth account_quotas proxy-server

[filter:account_quotas]
use = egg:swift#account_quotas

To set the quota on an account:

swift -A http://127.0.0.1:8080/auth/v1.0 -U account:reseller -K secret post -m quota-bytes:10000

Remove the quota:

swift -A http://127.0.0.1:8080/auth/v1.0 -U account:reseller -K secret post -m quota-bytes:

The same limitations apply for the account quotas as for the container quotas.

For example, when uploading an object without a content-length header the proxy server doesn’t know the final size of the currently uploaded object and the upload will be allowed if the current account size is within the quota. Due to the eventual consistency further uploads might be possible until the account size has been updated.

class swift.common.middleware.account_quotas.AccountQuotaMiddleware(app, *args, **kwargs)¶

Bases: object

Account quota middleware

See above for a full description.

swift.common.middleware.account_quotas.filter_factory(global_conf, **local_conf)¶

Returns a WSGI filter app for use with paste.deploy.

Bulk Operations (Delete and Archive Auto Extraction)¶

Middleware that will perform many operations on a single request.

/v1/AUTH_Account/$UPLOAD_PATH?extract-archive=tar.gz

/v1/AUTH_Account/$UPLOAD_PATH/$FILE_PATH

X-Detect-Content-Type: true

curl -X PUT http://127.0.0.1/v1/AUTH_acc/cont/$?extract-archive=tar
 -T backup.tar
 -H "Content-Type: application/x-tar"
 -H "X-Auth-Token: xxx"
 -H "X-Detect-Content-Type: true"

setfattr -n user.mime_type -v "application/python-setup" setup.py
setfattr -n user.meta.lunch -v "burger and fries" setup.py
setfattr -n user.meta.dinner -v "baked ziti" setup.py
setfattr -n user.stuff -v "whee" setup.py

Content-Type: application/python-setup
X-Object-Meta-Lunch: burger and fries
X-Object-Meta-Dinner: baked ziti

{"Response Status": "201 Created",
 "Response Body": "",
 "Errors": [],
 "Number Files Created": 10}

/container_name/obj_name

/container_name

{"Number Not Found": 0,
 "Response Status": "200 OK",
 "Response Body": "",
 "Errors": [],
 "Number Deleted": 6}

CatchErrors¶

class swift.common.middleware.catch_errors.CatchErrorMiddleware(app, conf)¶

Bases: object

Middleware that provides high-level error handling and ensures that a transaction id will be set for every request.

CNAME Lookup¶

CNAME Lookup Middleware

Middleware that translates an unknown domain in the host header to something that ends with the configured storage_domain by looking up the given domain’s CNAME record in DNS.

This middleware will continue to follow a CNAME chain in DNS until it finds a record ending in the configured storage domain or it reaches the configured maximum lookup depth. If a match is found, the environment’s Host header is rewritten and the request is passed further down the WSGI chain.

class swift.common.middleware.cname_lookup.CNAMELookupMiddleware(app, conf)¶

Bases: object

CNAME Lookup Middleware

See above for a full description.

Parameters:	app – The next WSGI filter or app in the paste.deploy chain. conf – The configuration dict for the middleware.

swift.common.middleware.cname_lookup.lookup_cname(domain, resolver)¶

Given a domain, returns its DNS CNAME mapping and DNS ttl.

Parameters:	domain – domain to query on resolver – dns.resolver.Resolver() instance used for executing DNS queries
Returns:	(ttl, result)

Container Quotas¶

The container_quotas middleware implements simple quotas that can be imposed on swift containers by a user with the ability to set container metadata, most likely the account administrator. This can be useful for limiting the scope of containers that are delegated to non-admin users, exposed to formpost uploads, or just as a self-imposed sanity check.

Any object PUT operations that exceed these quotas return a 413 response (request entity too large) with a descriptive body.

Quotas are subject to several limitations: eventual consistency, the timeliness of the cached container_info (60 second ttl by default), and it’s unable to reject chunked transfer uploads that exceed the quota (though once the quota is exceeded, new chunked transfers will be refused).

Quotas are set by adding meta values to the container, and are validated when set:

The container_quotas middleware should be added to the pipeline in your /etc/swift/proxy-server.conf file just after any auth middleware. For example:

[pipeline:main]
pipeline = catch_errors cache tempauth container_quotas proxy-server

[filter:container_quotas]
use = egg:swift#container_quotas

Container Sync Middleware¶

class swift.common.middleware.container_sync.ContainerSync(app, conf, logger=None)¶

Bases: object

WSGI middleware that validates an incoming container sync request using the container-sync-realms.conf style of container sync.

Cross Domain Policies¶

class swift.common.middleware.crossdomain.CrossDomainMiddleware(app, conf, *args, **kwargs)¶

Bases: object

Cross domain middleware used to respond to requests for cross domain policy information.

If the path is /crossdomain.xml it will respond with an xml cross domain policy document. This allows web pages hosted elsewhere to use client side technologies such as Flash, Java and Silverlight to interact with the Swift API.

To enable this middleware, add it to the pipeline in your proxy-server.conf file. It should be added before any authentication (e.g., tempauth or keystone) middleware. In this example ellipsis (…) indicate other middleware you may have chosen to use:

[pipeline:main]
pipeline =  ... crossdomain ... authtoken ... proxy-server

And add a filter section, such as:

[filter:crossdomain]
use = egg:swift#crossdomain
cross_domain_policy = <allow-access-from domain="*.example.com" />
    <allow-access-from domain="www.example.com" secure="false" />

For continuation lines, put some whitespace before the continuation text. Ensure you put a completely blank line to terminate the cross_domain_policy value.

The cross_domain_policy name/value is optional. If omitted, the policy defaults as if you had specified:

cross_domain_policy = <allow-access-from domain="*" secure="false" />

GET(req)¶

Returns a 200 response with cross domain policy information

Discoverability¶

Swift will by default provide clients with an interface providing details about the installation. Unless disabled (i.e expose_info=false in Proxy Server Configuration), a GET request to /info will return configuration data in JSON format. An example response:

{"swift": {"version": "1.11.0"}, "staticweb": {}, "tempurl": {}}

This would signify to the client that swift version 1.11.0 is running and that staticweb and tempurl are available in this installation.

There may be administrator-only information available via /info. To retrieve it, one must use an HMAC-signed request, similar to TempURL. The signature may be produced like so:

swift tempurl GET 3600 /info secret 2>/dev/null | sed s/temp_url/swiftinfo/g

Domain Remap¶

Domain Remap Middleware

Middleware that translates container and account parts of a domain to path parameters that the proxy server understands.

Translation is only performed when the request URL’s host domain matches one of a list of domains. This list may be configured by the option storage_domain, and defaults to the single domain example.com.

If not already present, a configurable path_root, which defaults to v1, will be added to the start of the translated path.

For example, with the default configuration:

container.AUTH-account.example.com/object
container.AUTH-account.example.com/v1/object

would both be translated to:

container.AUTH-account.example.com/v1/AUTH_account/container/object

and:

AUTH-account.example.com/container/object
AUTH-account.example.com/v1/container/object

would both be translated to:

AUTH-account.example.com/v1/AUTH_account/container/object

Additionally, translation is only performed when the account name in the translated path starts with a reseller prefix matching one of a list configured by the option reseller_prefixes, or when no match is found but a default_reseller_prefix has been configured.

The reseller_prefixes list defaults to the single prefix AUTH. The default_reseller_prefix is not configured by default.

Browsers can convert a host header to lowercase, so the middleware checks that the reseller prefix on the account name is the correct case. This is done by comparing the items in the reseller_prefixes config option to the found prefix. If they match except for case, the item from reseller_prefixes will be used instead of the found reseller prefix. The middleware will also replace any hyphen (‘-‘) in the account name with an underscore (‘_’).

For example, with the default configuration:

auth-account.example.com/container/object
AUTH-account.example.com/container/object
auth_account.example.com/container/object
AUTH_account.example.com/container/object

would all be translated to:

<unchanged>.example.com/v1/AUTH_account/container/object

When no match is found in reseller_prefixes, the default_reseller_prefix config option is used. When no default_reseller_prefix is configured, any request with an account prefix not in the reseller_prefixes list will be ignored by this middleware.

For example, with default_reseller_prefix = AUTH:

account.example.com/container/object

would be translated to:

account.example.com/v1/AUTH_account/container/object

Note that this middleware requires that container names and account names (except as described above) must be DNS-compatible. This means that the account name created in the system and the containers created by users cannot exceed 63 characters or have UTF-8 characters. These are restrictions over and above what Swift requires and are not explicitly checked. Simply put, this middleware will do a best-effort attempt to derive account and container names from elements in the domain name and put those derived values into the URL path (leaving the Host header unchanged).

Also note that using Container to Container Synchronization with remapped domain names is not advised. With Container to Container Synchronization, you should use the true storage end points as sync destinations.

class swift.common.middleware.domain_remap.DomainRemapMiddleware(app, conf)¶

Bases: object

Domain Remap Middleware

See above for a full description.

Parameters:	app – The next WSGI filter or app in the paste.deploy chain. conf – The configuration dict for the middleware.

Dynamic Large Objects¶

DLO support centers around a user specified filter that matches segments and concatenates them together in object listing order. Please see the DLO docs for Dynamic Large Objects further details.

Encryption¶

Encryption middleware should be deployed in conjunction with the Keymaster middleware.

Implements middleware for object encryption which comprises an instance of a Decrypter combined with an instance of an Encrypter.

swift.common.middleware.crypto.filter_factory(global_conf, **local_conf)¶

Provides a factory function for loading encryption middleware.

class swift.common.middleware.crypto.encrypter.EncInputWrapper(crypto, keys, req, logger)¶

Bases: object

File-like object to be swapped in for wsgi.input.

class swift.common.middleware.crypto.encrypter.Encrypter(app, conf)¶

Bases: object

Middleware for encrypting data and user metadata.

By default all PUT or POST’ed object data and/or metadata will be encrypted. Encryption of new data and/or metadata may be disabled by setting the disable_encryption option to True. However, this middleware should remain in the pipeline in order for existing encrypted data to be read.

swift.common.middleware.crypto.encrypter.encrypt_header_val(crypto, value, key)¶

Encrypt a header value using the supplied key.

Parameters:	crypto – a Crypto instance value – value to encrypt key – crypto key to use
Returns:	a tuple of (encrypted value, crypto_meta) where crypto_meta is a dict of form returned by get_crypto_meta()
Raises:	ValueError – if value is empty

class swift.common.middleware.crypto.decrypter.Decrypter(app, conf)¶

Bases: object

Middleware for decrypting data and user metadata.

FormPost¶

FormPost Middleware

Translates a browser form post into a regular Swift object PUT.

The format of the form is:

<form action="<swift-url>" method="POST"
      enctype="multipart/form-data">
  <input type="hidden" name="redirect" value="<redirect-url>" />
  <input type="hidden" name="max_file_size" value="<bytes>" />
  <input type="hidden" name="max_file_count" value="<count>" />
  <input type="hidden" name="expires" value="<unix-timestamp>" />
  <input type="hidden" name="signature" value="<hmac>" />
  <input type="file" name="file1" /><br />
  <input type="submit" />
</form>

Optionally, if you want the uploaded files to be temporary you can set x-delete-at or x-delete-after attributes by adding one of these as a form input:

<input type="hidden" name="x_delete_at" value="<unix-timestamp>" />
<input type="hidden" name="x_delete_after" value="<seconds>" />

The <swift-url> is the URL of the Swift destination, such as:

https://swift-cluster.example.com/v1/AUTH_account/container/object_prefix

The name of each file uploaded will be appended to the <swift-url> given. So, you can upload directly to the root of container with a url like:

https://swift-cluster.example.com/v1/AUTH_account/container/

Optionally, you can include an object prefix to better separate different users’ uploads, such as:

https://swift-cluster.example.com/v1/AUTH_account/container/object_prefix

Note the form method must be POST and the enctype must be set as “multipart/form-data”.

The redirect attribute is the URL to redirect the browser to after the upload completes. This is an optional parameter. If you are uploading the form via an XMLHttpRequest the redirect should not be included. The URL will have status and message query parameters added to it, indicating the HTTP status code for the upload (2xx is success) and a possible message for further information if there was an error (such as “max_file_size exceeded”).

The max_file_size attribute must be included and indicates the largest single file upload that can be done, in bytes.

The max_file_count attribute must be included and indicates the maximum number of files that can be uploaded with the form. Include additional <input type="file" name="filexx" /> attributes if desired.

The expires attribute is the Unix timestamp before which the form must be submitted before it is invalidated.

The signature attribute is the HMAC-SHA1 signature of the form. Here is sample code for computing the signature:

import hmac
from hashlib import sha1
from time import time
path = '/v1/account/container/object_prefix'
redirect = 'https://srv.com/some-page'  # set to '' if redirect not in form
max_file_size = 104857600
max_file_count = 10
expires = int(time() + 600)
key = 'mykey'
hmac_body = '%s\n%s\n%s\n%s\n%s' % (path, redirect,
    max_file_size, max_file_count, expires)
signature = hmac.new(key, hmac_body, sha1).hexdigest()

The key is the value of either the account (X-Account-Meta-Temp-URL-Key, X-Account-Meta-Temp-Url-Key-2) or the container (X-Container-Meta-Temp-URL-Key, X-Container-Meta-Temp-Url-Key-2) TempURL keys.

Be certain to use the full path, from the /v1/ onward. Note that x_delete_at and x_delete_after are not used in signature generation as they are both optional attributes.

The command line tool swift-form-signature may be used (mostly just when testing) to compute expires and signature.

Also note that the file attributes must be after the other attributes in order to be processed correctly. If attributes come after the file, they won’t be sent with the subrequest (there is no way to parse all the attributes on the server-side without reading the whole thing into memory – to service many requests, some with large files, there just isn’t enough memory on the server, so attributes following the file are simply ignored).

class swift.common.middleware.formpost.FormPost(app, conf)¶

Bases: object

FormPost Middleware

See above for a full description.

The proxy logs created for any subrequests made will have swift.source set to “FP”.

Parameters:	app – The next WSGI filter or app in the paste.deploy chain. conf – The configuration dict for the middleware.

app = None¶

The next WSGI application/filter in the paste.deploy pipeline.

conf = None¶

The filter configuration dict.

swift.common.middleware.formpost.filter_factory(global_conf, **local_conf)¶

Returns the WSGI filter for use with paste.deploy.

swift.common.middleware.formpost.READ_CHUNK_SIZE = 4096¶

The size of data to read from the form at any given time.

swift.common.middleware.formpost.MAX_VALUE_LENGTH = 4096¶

The maximum size of any attribute’s value. Any additional data will be truncated.

GateKeeper¶

The gatekeeper middleware imposes restrictions on the headers that may be included with requests and responses. Request headers are filtered to remove headers that should never be generated by a client. Similarly, response headers are filtered to remove private headers that should never be passed to a client.

The gatekeeper middleware must always be present in the proxy server wsgi pipeline. It should be configured close to the start of the pipeline specified in /etc/swift/proxy-server.conf, immediately after catch_errors and before any other middleware. It is essential that it is configured ahead of all middlewares using system metadata in order that they function correctly.

If gatekeeper middleware is not configured in the pipeline then it will be automatically inserted close to the start of the pipeline by the proxy server.

swift.common.middleware.gatekeeper.inbound_exclusions = ['x-account-sysmeta-', 'x-container-sysmeta-', 'x-object-sysmeta-', 'x-object-transient-sysmeta-', 'x-backend']¶

A list of python regular expressions that will be used to match against inbound request headers. Matching headers will be removed from the request.

swift.common.middleware.gatekeeper.outbound_exclusions = ['x-account-sysmeta-', 'x-container-sysmeta-', 'x-object-sysmeta-', 'x-object-transient-sysmeta-', 'x-backend']¶

A list of python regular expressions that will be used to match against outbound response headers. Matching headers will be removed from the response.

Healthcheck¶

class swift.common.middleware.healthcheck.HealthCheckMiddleware(app, conf)¶

Bases: object

Healthcheck middleware used for monitoring.

If the path is /healthcheck, it will respond 200 with “OK” as the body.

If the optional config parameter “disable_path” is set, and a file is present at that path, it will respond 503 with “DISABLED BY FILE” as the body.

DISABLED(req)¶

Returns a 503 response with “DISABLED BY FILE” in the body.

GET(req)¶

Returns a 200 response with “OK” in the body.

Keymaster¶

Keymaster middleware should be deployed in conjunction with the Encryption middleware.

class swift.common.middleware.crypto.keymaster.KeyMaster(app, conf)¶

Bases: object

Middleware for providing encryption keys.

The middleware requires its encryption root secret to be set. This is the root secret from which encryption keys are derived. This must be set before first use to a value that is at least 256 bits. The security of all encrypted data critically depends on this key, therefore it should be set to a high-entropy value. For example, a suitable value may be obtained by generating a 32 byte (or longer) value using a cryptographically secure random number generator. Changing the root secret is likely to result in data loss.

class swift.common.middleware.crypto.keymaster.KeyMasterContext(keymaster, account, container, obj)¶

Bases: swift.common.wsgi.WSGIContext

The simple scheme for key derivation is as follows: every path is associated with a key, where the key is derived from the path itself in a deterministic fashion such that the key does not need to be stored. Specifically, the key for any path is an HMAC of a root key and the path itself, calculated using an SHA256 hash function:

<path_key> = HMAC_SHA256(<root_secret>, <path>)

fetch_crypto_keys(*args, **kwargs)¶

Setup container and object keys based on the request path.

Keys are derived from request path. The ‘id’ entry in the results dict includes the part of the path used to derive keys. Other keymaster implementations may use a different strategy to generate keys and may include a different type of ‘id’, so callers should treat the ‘id’ as opaque keymaster-specific data.

Returns:	A dict containing encryption keys for ‘object’ and ‘container’ and a key ‘id’.

KeystoneAuth¶

class swift.common.middleware.keystoneauth.KeystoneAuth(app, conf)¶

Bases: object

Swift middleware to Keystone authorization system.

In Swift’s proxy-server.conf add this keystoneauth middleware and the authtoken middleware to your pipeline. Make sure you have the authtoken middleware before the keystoneauth middleware.

The authtoken middleware will take care of validating the user and keystoneauth will authorize access.

The sample proxy-server.conf shows a sample pipeline that uses keystone.

proxy-server.conf-sample

The authtoken middleware is shipped with keystonemiddleware - it does not have any other dependencies than itself so you can either install it by copying the file directly in your python path or by installing keystonemiddleware.

If support is required for unvalidated users (as with anonymous access) or for formpost/staticweb/tempurl middleware, authtoken will need to be configured with delay_auth_decision set to true. See the Keystone documentation for more detail on how to configure the authtoken middleware.

In proxy-server.conf you will need to have the setting account auto creation to true:

[app:proxy-server]
account_autocreate = true

And add a swift authorization filter section, such as:

[filter:keystoneauth]
use = egg:swift#keystoneauth
operator_roles = admin, swiftoperator

The user who is able to give ACL / create Containers permissions will be the user with a role listed in the operator_roles setting which by default includes the admin and the swiftoperator roles.

The keystoneauth middleware maps a Keystone project/tenant to an account in Swift by adding a prefix (AUTH_ by default) to the tenant/project id.. For example, if the project id is 1234, the path is /v1/AUTH_1234.

If you need to have a different reseller_prefix to be able to mix different auth servers you can configure the option reseller_prefix in your keystoneauth entry like this:

reseller_prefix = NEWAUTH

Don’t forget to also update the Keystone service endpoint configuration to use NEWAUTH in the path.

It is possible to have several accounts associated with the same project. This is done by listing several prefixes as shown in the following example:

reseller_prefix = AUTH, SERVICE

This means that for project id ‘1234’, the paths ‘/v1/AUTH_1234’ and ‘/v1/SERVICE_1234’ are associated with the project and are authorized using roles that a user has with that project. The core use of this feature is that it is possible to provide different rules for each account prefix. The following parameters may be prefixed with the appropriate prefix:

operator_roles
service_roles

For backward compatibility, if either of these parameters is specified without a prefix then it applies to all reseller_prefixes. Here is an example, using two prefixes:

reseller_prefix = AUTH, SERVICE
# The next three lines have identical effects (since the first applies
# to both prefixes).
operator_roles = admin, swiftoperator
AUTH_operator_roles = admin, swiftoperator
SERVICE_operator_roles = admin, swiftoperator
# The next line only applies to accounts with the SERVICE prefix
SERVICE_operator_roles = admin, some_other_role

X-Service-Token tokens are supported by the inclusion of the service_roles configuration option. When present, this option requires that the X-Service-Token header supply a token from a user who has a role listed in service_roles. Here is an example configuration:

reseller_prefix = AUTH, SERVICE
AUTH_operator_roles = admin, swiftoperator
SERVICE_operator_roles = admin, swiftoperator
SERVICE_service_roles = service

The keystoneauth middleware supports cross-tenant access control using the syntax <tenant>:<user> to specify a grantee in container Access Control Lists (ACLs). For a request to be granted by an ACL, the grantee <tenant> must match the UUID of the tenant to which the request X-Auth-Token is scoped and the grantee <user> must match the UUID of the user authenticated by that token.

Note that names must no longer be used in cross-tenant ACLs because with the introduction of domains in keystone names are no longer globally unique.

For backwards compatibility, ACLs using names will be granted by keystoneauth when it can be established that the grantee tenant, the grantee user and the tenant being accessed are either not yet in a domain (e.g. the X-Auth-Token has been obtained via the keystone v2 API) or are all in the default domain to which legacy accounts would have been migrated. The default domain is identified by its UUID, which by default has the value default. This can be changed by setting the default_domain_id option in the keystoneauth configuration:

default_domain_id = default

The backwards compatible behavior can be disabled by setting the config option allow_names_in_acls to false:

allow_names_in_acls = false

To enable this backwards compatibility, keystoneauth will attempt to determine the domain id of a tenant when any new account is created, and persist this as account metadata. If an account is created for a tenant using a token with reselleradmin role that is not scoped on that tenant, keystoneauth is unable to determine the domain id of the tenant; keystoneauth will assume that the tenant may not be in the default domain and therefore not match names in ACLs for that account.

By default, middleware higher in the WSGI pipeline may override auth processing, useful for middleware such as tempurl and formpost. If you know you’re not going to use such middleware and you want a bit of extra security you can disable this behaviour by setting the allow_overrides option to false:

allow_overrides = false

Parameters:	app – The next WSGI app in the pipeline conf – The dict of configuration values

authorize_anonymous(req)¶

Authorize an anonymous request.

Returns:	None if authorization is granted, an error page otherwise.

denied_response(req)¶

Deny WSGI Response.

Returns a standard WSGI response callable with the status of 403 or 401 depending on whether the REMOTE_USER is set or not.

swift.common.middleware.keystoneauth.filter_factory(global_conf, **local_conf)¶

Returns a WSGI filter app for use with paste.deploy.

List Endpoints¶

List endpoints for an object, account or container.

This middleware makes it possible to integrate swift with software that relies on data locality information to avoid network overhead, such as Hadoop.

Using the original API, answers requests of the form:

/endpoints/{account}/{container}/{object}
/endpoints/{account}/{container}
/endpoints/{account}
/endpoints/v1/{account}/{container}/{object}
/endpoints/v1/{account}/{container}
/endpoints/v1/{account}

with a JSON-encoded list of endpoints of the form:

http://{server}:{port}/{dev}/{part}/{acc}/{cont}/{obj}
http://{server}:{port}/{dev}/{part}/{acc}/{cont}
http://{server}:{port}/{dev}/{part}/{acc}

correspondingly, e.g.:

http://10.1.1.1:6200/sda1/2/a/c2/o1
http://10.1.1.1:6200/sda1/2/a/c2
http://10.1.1.1:6200/sda1/2/a

Using the v2 API, answers requests of the form:

/endpoints/v2/{account}/{container}/{object}
/endpoints/v2/{account}/{container}
/endpoints/v2/{account}

with a JSON-encoded dictionary containing a key ‘endpoints’ that maps to a list of endpoints having the same form as described above, and a key ‘headers’ that maps to a dictionary of headers that should be sent with a request made to the endpoints, e.g.:

{ "endpoints": {"http://10.1.1.1:6010/sda1/2/a/c3/o1",
                "http://10.1.1.1:6030/sda3/2/a/c3/o1",
                "http://10.1.1.1:6040/sda4/2/a/c3/o1"},
  "headers": {"X-Backend-Storage-Policy-Index": "1"}}

In this example, the ‘headers’ dictionary indicates that requests to the endpoint URLs should include the header ‘X-Backend-Storage-Policy-Index: 1’ because the object’s container is using storage policy index 1.

The ‘/endpoints/’ path is customizable (‘list_endpoints_path’ configuration parameter).

Intended for consumption by third-party services living inside the cluster (as the endpoints make sense only inside the cluster behind the firewall); potentially written in a different language.

This is why it’s provided as a REST API and not just a Python API: to avoid requiring clients to write their own ring parsers in their languages, and to avoid the necessity to distribute the ring file to clients and keep it up-to-date.

Note that the call is not authenticated, which means that a proxy with this middleware enabled should not be open to an untrusted environment (everyone can query the locality data using this middleware).

class swift.common.middleware.list_endpoints.ListEndpointsMiddleware(app, conf)¶

Bases: object

List endpoints for an object, account or container.

See above for a full description.

Uses configuration parameter swift_dir (default /etc/swift).

Parameters:	app – The next WSGI filter or app in the paste.deploy chain. conf – The configuration dict for the middleware.

get_object_ring(policy_idx)¶

Get the ring object to use to handle a request based on its policy.

Policy_idx:	policy index as defined in swift.conf
Returns:	appropriate ring object

Memcache¶

class swift.common.middleware.memcache.MemcacheMiddleware(app, conf)¶

Bases: object

Caching middleware that manages caching in swift.

Name Check (Forbidden Character Filter)¶

Created on February 27, 2012

A filter that disallows any paths that contain defined forbidden characters or that exceed a defined length.

Place early in the proxy-server pipeline after the left-most occurrence of the proxy-logging middleware (if present) and before the final proxy-logging middleware (if present) or the proxy-serer app itself, e.g.:

[pipeline:main]
pipeline = catch_errors healthcheck proxy-logging name_check cache ratelimit tempauth sos proxy-logging proxy-server

[filter:name_check]
use = egg:swift#name_check
forbidden_chars = '"`<>
maximum_length = 255

There are default settings for forbidden_chars (FORBIDDEN_CHARS) and maximum_length (MAX_LENGTH)

The filter returns HTTPBadRequest if path is invalid.

@author: eamonn-otoole

Object Versioning¶

Object versioning in swift is implemented by setting a flag on the container to tell swift to version all objects in the container. The value of the flag is the container where the versions are stored (commonly referred to as the “archive container”). The flag itself is one of two headers, which determines how object DELETE requests are handled:

• X-History-Location

  On DELETE, copy the current version of the object to the archive container, write a zero-byte “delete marker” object that notes when the delete took place, and delete the object from the versioned container. The object will no longer appear in container listings for the versioned container and future requests there will return 404 Not Found. However, the content will still be recoverable from the archive container.

• X-Versions-Location

  On DELETE, only remove the current version of the object. If any previous versions exist in the archive container, the most recent one is copied over the current version, and the copy in the archive container is deleted. As a result, if you have 5 total versions of the object, you must delete the object 5 times for that object name to start responding with 404 Not Found.

Either header may be used for the various containers within an account, but only one may be set for any given container. Attempting to set both simulataneously will result in a 400 Bad Request response.

When data is PUT into a versioned container (a container with the versioning flag turned on), the existing data in the file is redirected to a new object in the archive container and the data in the PUT request is saved as the data for the versioned object. The new object name (for the previous version) is <archive_container>/<length><object_name>/<timestamp>, where length is the 3-character zero-padded hexadecimal length of the <object_name> and <timestamp> is the timestamp of when the previous version was created.

A GET to a versioned object will return the current version of the object without having to do any request redirects or metadata lookups.

A POST to a versioned object will update the object metadata as normal, but will not create a new version of the object. In other words, new versions are only created when the content of the object changes.

A DELETE to a versioned object will be handled in one of two ways, as described above.

To restore a previous version of an object, find the desired version in the archive container then issue a COPY with a Destination header indicating the original location. This will archive the current version similar to a PUT over the versioned object. If the client additionally wishes to permanently delete what was the current version, it must find the newly-created archive in the archive container and issue a separate DELETE to it.

curl -i -XPUT -H "X-Auth-Token: <token>" -H "X-Versions-Location: versions" http://<storage_url>/container
curl -i -XPUT -H "X-Auth-Token: <token>" http://<storage_url>/versions

curl -i -XPUT --data-binary 1 -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -XPUT --data-binary 2 -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -H "X-Auth-Token: <token>" http://<storage_url>/versions?prefix=008myobject/

curl -i -XDELETE -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject
curl -i -H "X-Auth-Token: <token>" http://<storage_url>/versions?prefix=008myobject/
curl -i -XGET -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -XPUT -H "X-Auth-Token: <token>" -H "X-History-Location: versions" http://<storage_url>/container
curl -i -XPUT -H "X-Auth-Token: <token>" http://<storage_url>/versions

curl -i -XPUT --data-binary 1 -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -XPUT --data-binary 2 -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -XDELETE -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject
curl -i -H "X-Auth-Token: <token>" http://<storage_url>/container/myobject

curl -i -H "X-Auth-Token: <token>" http://<storage_url>/versions?prefix=008myobject/

curl -i -XCOPY -H "X-Auth-Token: <token>" http://<storage_url>/versions/008myobject/<timestamp> -H "Destination: container/myobject"

curl -i -H "X-Auth-Token: <token>" http://<storage_url>/versions?prefix=008myobject/

curl -i -XDELETE -H "X-Auth-Token: <token>" http://<storage_url>/versions/008myobject/<timestamp>

curl -i -XPOST -H "X-Auth-Token: <token>" -H "X-Remove-Versions-Location: x" http://<storage_url>/container

Proxy Logging¶

Logging middleware for the Swift proxy.

This serves as both the default logging implementation and an example of how to plug in your own logging format/method.

The logging format implemented below is as follows:

client_ip remote_addr datetime request_method request_path protocol

status_int referer user_agent auth_token bytes_recvd bytes_sent client_etag transaction_id headers request_time source log_info request_start_time request_end_time

These values are space-separated, and each is url-encoded, so that they can be separated with a simple .split()

• remote_addr is the contents of the REMOTE_ADDR environment variable, while client_ip is swift’s best guess at the end-user IP, extracted variously from the X-Forwarded-For header, X-Cluster-Ip header, or the REMOTE_ADDR environment variable.
• source (swift.source in the WSGI environment) indicates the code that generated the request, such as most middleware. (See below for more detail.)
• log_info (swift.log_info in the WSGI environment) is for additional information that could prove quite useful, such as any x-delete-at value or other “behind the scenes” activity that might not otherwise be detectable from the plain log information. Code that wishes to add additional log information should use code like env.setdefault('swift.log_info', []).append(your_info) so as to not disturb others’ log information.
• Values that are missing (e.g. due to a header not being present) or zero are generally represented by a single hyphen (‘-‘).

The proxy-logging can be used twice in the proxy server’s pipeline when there is middleware installed that can return custom responses that don’t follow the standard pipeline to the proxy server.

For example, with staticweb, the middleware might intercept a request to /v1/AUTH_acc/cont/, make a subrequest to the proxy to retrieve /v1/AUTH_acc/cont/index.html and, in effect, respond to the client’s original request using the 2nd request’s body. In this instance the subrequest will be logged by the rightmost middleware (with a swift.source set) and the outgoing request (with body overridden) will be logged by leftmost middleware.

Requests that follow the normal pipeline (use the same wsgi environment throughout) will not be double logged because an environment variable (swift.proxy_access_log_made) is checked/set when a log is made.

All middleware making subrequests should take care to set swift.source when needed. With the doubled proxy logs, any consumer/processor of swift’s proxy logs should look at the swift.source field, the rightmost log value, to decide if this is a middleware subrequest or not. A log processor calculating bandwidth usage will want to only sum up logs with no swift.source.

class swift.common.middleware.proxy_logging.ProxyLoggingMiddleware(app, conf, logger=None)¶

Bases: object

Middleware that logs Swift proxy requests in the swift log format.

log_request(req, status_int, bytes_received, bytes_sent, start_time, end_time, resp_headers=None)¶

Log a request.

Parameters:	req – swob.Request object for the request status_int – integer code for the response status bytes_received – bytes successfully read from the request body bytes_sent – bytes yielded to the WSGI server start_time – timestamp request started end_time – timestamp request completed resp_headers – dict of the response headers

Ratelimit¶

class swift.common.middleware.ratelimit.RateLimitMiddleware(app, conf, logger=None)¶

Bases: object

Rate limiting middleware

Rate limits requests on both an Account and Container level. Limits are configurable.

get_ratelimitable_key_tuples(req, account_name, container_name=None, obj_name=None, global_ratelimit=None)¶

Returns a list of key (used in memcache), ratelimit tuples. Keys should be checked in order.

Parameters:	req – swob request account_name – account name from path container_name – container name from path obj_name – object name from path global_ratelimit – this account has an account wide ratelimit on all writes combined

handle_ratelimit(req, account_name, container_name, obj_name)¶

Performs rate limiting and account white/black listing. Sleeps if necessary. If self.memcache_client is not set, immediately returns None.

Parameters:	account_name – account name from path container_name – container name from path obj_name – object name from path

swift.common.middleware.ratelimit.filter_factory(global_conf, **local_conf)¶

paste.deploy app factory for creating WSGI proxy apps.

swift.common.middleware.ratelimit.get_maxrate(ratelimits, size)¶

Returns number of requests allowed per second for given size.

swift.common.middleware.ratelimit.interpret_conf_limits(conf, name_prefix, info=None)¶

Parses general parms for rate limits looking for things that start with the provided name_prefix within the provided conf and returns lists for both internal use and for /info

Parameters:	conf – conf dict to parse name_prefix – prefix of config parms to look for info – set to return extra stuff for /info registration

Recon¶

class swift.common.middleware.recon.ReconMiddleware(app, conf, *args, **kwargs)¶

Bases: object

Recon middleware used for monitoring.

/recon/load|mem|async… will return various system metrics.

Needs to be added to the pipeline and requires a filter declaration in the object-server.conf:

[filter:recon] use = egg:swift#recon recon_cache_path = /var/cache/swift

get_async_info()¶

get # of async pendings

get_auditor_info(recon_type)¶

get auditor info

get_device_info()¶

get devices

get_diskusage()¶

get disk utilization statistics

get_driveaudit_error()¶

get # of drive audit errors

get_expirer_info(recon_type)¶

get expirer info

get_load(openr=<built-in function open>)¶

get info from /proc/loadavg

get_mem(openr=<built-in function open>)¶

get info from /proc/meminfo

get_mounted(openr=<built-in function open>)¶

get ALL mounted fs from /proc/mounts

get_quarantine_count()¶

get obj/container/account quarantine counts

get_replication_info(recon_type)¶

get replication info

get_ring_md5()¶

get all ring md5sum’s

get_socket_info(openr=<built-in function open>)¶

get info from /proc/net/sockstat and sockstat6

Note: The mem value is actually kernel pages, but we return bytes allocated based on the systems page size.

get_swift_conf_md5()¶

get md5 of swift.conf

get_time()¶

get current time

get_unmounted()¶

list unmounted (failed?) devices

get_updater_info(recon_type)¶

get updater info

get_version()¶

get swift version

Server Side Copy¶

Server side copy is a feature that enables users/clients to COPY objects between accounts and containers without the need to download and then re-upload objects, thus eliminating additional bandwidth consumption and also saving time. This may be used when renaming/moving an object which in Swift is a (COPY + DELETE) operation.

The server side copy middleware should be inserted in the pipeline after auth and before the quotas and large object middlewares. If it is not present in the pipeline in the proxy-server configuration file, it will be inserted automatically. There is no configurable option provided to turn off server side copy.

?multipart-manifest=get

Static Large Objects¶

Please see the SLO docs for Static Large Objects further details.

StaticWeb¶

This StaticWeb WSGI middleware will serve container data as a static web site with index file and error file resolution and optional file listings. This mode is normally only active for anonymous requests. When using keystone for authentication set delay_auth_decision = true in the authtoken middleware configuration in your /etc/swift/proxy-server.conf file. If you want to use it with authenticated requests, set the X-Web-Mode: true header on the request.

The staticweb filter should be added to the pipeline in your /etc/swift/proxy-server.conf file just after any auth middleware. Also, the configuration section for the staticweb middleware itself needs to be added. For example:

[DEFAULT]
...

[pipeline:main]
pipeline = catch_errors healthcheck proxy-logging cache ratelimit tempauth
           staticweb proxy-logging proxy-server

...

[filter:staticweb]
use = egg:swift#staticweb

Any publicly readable containers (for example, X-Container-Read: .r:*, see ACLs for more information on this) will be checked for X-Container-Meta-Web-Index and X-Container-Meta-Web-Error header values:

X-Container-Meta-Web-Index  <index.name>
X-Container-Meta-Web-Error  <error.name.suffix>

If X-Container-Meta-Web-Index is set, any <index.name> files will be served without having to specify the <index.name> part. For instance, setting X-Container-Meta-Web-Index: index.html will be able to serve the object …/pseudo/path/index.html with just …/pseudo/path or …/pseudo/path/

If X-Container-Meta-Web-Error is set, any errors (currently just 401 Unauthorized and 404 Not Found) will instead serve the …/<status.code><error.name.suffix> object. For instance, setting X-Container-Meta-Web-Error: error.html will serve …/404error.html for requests for paths not found.

For pseudo paths that have no <index.name>, this middleware can serve HTML file listings if you set the X-Container-Meta-Web-Listings: true metadata item on the container.

If listings are enabled, the listings can have a custom style sheet by setting the X-Container-Meta-Web-Listings-CSS header. For instance, setting X-Container-Meta-Web-Listings-CSS: listing.css will make listings link to the …/listing.css style sheet. If you “view source” in your browser on a listing page, you will see the well defined document structure that can be styled.

By default, the listings will be rendered with a label of “Listing of /v1/account/container/path”. This can be altered by setting a X-Container-Meta-Web-Listings-Label: <label>. For example, if the label is set to “example.com”, a label of “Listing of example.com/path” will be used instead.

The content-type of directory marker objects can be modified by setting the X-Container-Meta-Web-Directory-Type header. If the header is not set, application/directory is used by default. Directory marker objects are 0-byte objects that represent directories to create a simulated hierarchical structure.

Example usage of this middleware via swift:

Make the container publicly readable:

swift post -r '.r:*' container

You should be able to get objects directly, but no index.html resolution or listings.

Set an index file directive:

swift post -m 'web-index:index.html' container

You should be able to hit paths that have an index.html without needing to type the index.html part.

Turn on listings:

swift post -r '.r:*,.rlistings' container
swift post -m 'web-listings: true' container

Now you should see object listings for paths and pseudo paths that have no index.html.

Enable a custom listings style sheet:

swift post -m 'web-listings-css:listings.css' container

Set an error file:

swift post -m 'web-error:error.html' container

Now 401’s should load 401error.html, 404’s should load 404error.html, etc.

Set Content-Type of directory marker object:

swift post -m 'web-directory-type:text/directory' container

Now 0-byte objects with a content-type of text/directory will be treated as directories rather than objects.

class swift.common.middleware.staticweb.StaticWeb(app, conf)¶

Bases: object

The Static Web WSGI middleware filter; serves container data as a static web site. See staticweb for an overview.

The proxy logs created for any subrequests made will have swift.source set to “SW”.

Parameters:	app – The next WSGI application/filter in the paste.deploy pipeline. conf – The filter configuration dict.

app = None¶

The next WSGI application/filter in the paste.deploy pipeline.

conf = None¶

The filter configuration dict. Only used in tests.

swift.common.middleware.staticweb.filter_factory(global_conf, **local_conf)¶

Returns a Static Web WSGI filter for use with paste.deploy.

Symlink¶

Symlink Middleware

Symlinks are objects stored in Swift that contain a reference to another object (hereinafter, this is called “target object”). They are analogous to symbolic links in Unix-like operating systems. The existence of a symlink object does not affect the target object in any way. An important use case is to use a path in one container to access an object in a different container, with a different policy. This allows policy cost/performance trade-offs to be made on individual objects.

Clients create a Swift symlink by performing a zero-length PUT request with the header X-Symlink-Target: <container>/<object>. For a cross-account symlink, the header X-Symlink-Target-Account: <account> must be included. If omitted, it is inserted automatically with the account of the symlink object in the PUT request process.

Symlinks must be zero-byte objects. Attempting to PUT a symlink with a non-empty request body will result in a 400-series error. Also, POST with X-Symlink-Target header always results in a 400-series error. The target object need not exist at symlink creation time. It is suggested to set the Content-Type of symlink objects to a distinct value such as application/symlink.

A GET/HEAD request to a symlink will result in a request to the target object referenced by the symlink’s X-Symlink-Target-Account and X-Symlink-Target headers. The response of the GET/HEAD request will contain a Content-Location header with the path location of the target object. A GET/HEAD request to a symlink with the query parameter ?symlink=get will result in the request targeting the symlink itself.

A symlink can point to another symlink. Chained symlinks will be traversed until target is not a symlink. If the number of chained symlinks exceeds the limit symloop_max an error response will be produced. The value of symloop_max can be defined in the symlink config section of proxy-server.conf. If not specified, the default symloop_max value is 2. If a value less than 1 is specified, the default value will be used.

A HEAD/GET request to a symlink object behaves as a normal HEAD/GET request to the target object. Therefore issuing a HEAD request to the symlink will return the target metadata, and issuing a GET request to the symlink will return the data and metadata of the target object. To return the symlink metadata (with its empty body) a GET/HEAD request with the ?symlink=get query parameter must be sent to a symlink object.

A POST request to a symlink will result in a 307 TemporaryRedirect response. The response will contain a Location header with the path of the target object as the value. The request is never redirected to the target object by Swift. Nevertheless, the metadata in the POST request will be applied to the symlink because object servers cannot know for sure if the current object is a symlink or not in eventual consistency.

A DELETE request to a symlink will delete the symlink itself. The target object will not be deleted.

A COPY request, or a PUT request with a X-Copy-From header, to a symlink will copy the target object. The same request to a symlink with the query parameter ?symlink=get will copy the symlink itself.

An OPTIONS request to a symlink will respond with the options for the symlink only, the request will not be redirected to the target object. Please note that if the symlink’s target object is in another container with CORS settings, the response will not reflect the settings.

Tempurls can be used to GET/HEAD symlink objects, but PUT is not allowed and will result in a 400-series error. The GET/HEAD tempurls honor the scope of the tempurl key. Container tempurl will only work on symlinks where the target container is the same as the symlink. In case a symlink targets an object in a different container, a GET/HEAD request will result in a 401 Unauthorized error. The account level tempurl will allow cross container symlinks.

If a symlink object is overwritten while it is in a versioned container, the symlink object itself is versioned, not the referenced object.

A GET request with query parameter ?format=json to a container which contains symlinks will respond with additional information symlink_path for each symlink object in the container listing. The symlink_path value is the target path of the symlink. Clients can differentiate symlinks and other objects by this function. Note that responses of any other format (e.g.``?format=xml``) won’t include symlink_path info.

Errors

• PUT with the header X-Symlink-Target with non-zero Content-Length will produce a 400 BadRequest error.
• POST with the header X-Symlink-Target will produce a 400 BadRequest error.
• GET/HEAD traversing more than symloop_max chained symlinks will produce a 409 Conflict error.
• POSTs will produce a 307 TemporaryRedirect error.

TempAuth¶

Test authentication and authorization system.

Add to your pipeline in proxy-server.conf, such as:

[pipeline:main]
pipeline = catch_errors cache tempauth proxy-server

Set account auto creation to true in proxy-server.conf:

[app:proxy-server]
account_autocreate = true

And add a tempauth filter section, such as:

[filter:tempauth]
use = egg:swift#tempauth
user_admin_admin = admin .admin .reseller_admin
user_test_tester = testing .admin
user_test2_tester2 = testing2 .admin
user_test_tester3 = testing3
# To allow accounts/users with underscores you can base64 encode them.
# Here is the account "under_score" and username "a_b" (note the lack
# of padding equal signs):
user64_dW5kZXJfc2NvcmU_YV9i = testing4

See the proxy-server.conf-sample for more information.

user_<account>_<user> = <key> [group] [group] [...] [storage_url]

user64_<account_b64>_<user_b64> = <key> [group] [...] [storage_url]

$HOST/v1/<reseller_prefix>_<account>

[filter:tempauth]
use = egg:swift#tempauth
reseller_prefix = AUTH, SERVICE
SERVICE_require_group = .service
user_admin_admin = admin .admin .reseller_admin
user_joeacct_joe = joepw .admin
user_maryacct_mary = marypw .admin
user_glance_glance = glancepw .service

from swift.common.middleware.acl import format_acl
acl_data = { 'admin': ['alice'], 'read-write': ['bob', 'carol'] }
header_value = format_acl(version=2, acl_dict=acl_data)

token=...
storage_url=...
python -c '
  from swift.common.middleware.acl import format_acl
  acl_data = { 'admin': ['alice'], 'read-write': ['bob', 'carol'] }
  headers = {'X-Account-Access-Control':
             format_acl(version=2, acl_dict=acl_data)}
  header_str = ' '.join(["-H '%s: %s'" % (k, v)
                         for k, v in headers.items()])
  print('curl -D- -X POST -H "x-auth-token: $token" %s '
        '$storage_url' % header_str)
'

TempURL¶

TempURL Middleware

Allows the creation of URLs to provide temporary access to objects.

For example, a website may wish to provide a link to download a large object in Swift, but the Swift account has no public access. The website can generate a URL that will provide GET access for a limited time to the resource. When the web browser user clicks on the link, the browser will download the object directly from Swift, obviating the need for the website to act as a proxy for the request.

If the user were to share the link with all his friends, or accidentally post it on a forum, etc. the direct access would be limited to the expiration time set when the website created the link.

Beyond that, the middleware provides the ability to create URLs, which contain signatures which are valid for all objects which share a common prefix. These prefix-based URLs are useful for sharing a set of objects.

import hmac
from hashlib import sha1
from time import time
method = 'GET'
expires = int(time() + 60)
path = '/v1/AUTH_account/container/object'
key = 'mykey'
hmac_body = '%s\n%s\n%s' % (method, expires, path)
sig = hmac.new(key, hmac_body, sha1).hexdigest()

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485

import base64
import hmac
from hashlib import sha512
from time import time
method = 'GET'
expires = int(time() + 60)
path = '/v1/AUTH_account/container/object'
key = 'mykey'
hmac_body = '%s\n%s\n%s' % (method, expires, path)
sig = 'sha512:' + base64.urlsafe_b64encode(hmac.new(
    key, hmac_body, sha512).digest())

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=sha512:ZrSijn0GyDhsv1ltIj9hWUTrbAeE45NcKXyBaz7aPbSMvRO
Q4jtYH4nRAmm5ErY2X11Yc1Yhy2OMCyN3yueeXg==&
temp_url_expires=1516741234

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=2011-12-10T01:11:25Z

path = 'prefix:/v1/AUTH_account/container/pre'

https://swift-cluster.example.com/v1/AUTH_account/container/pre/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485&
temp_url_prefix=pre

https://swift-cluster.example.com/v1/AUTH_account/container/pre/
subfolder/another_object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485&
temp_url_prefix=pre

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485&filename=My+Test+File.pdf

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485&inline

https://swift-cluster.example.com/v1/AUTH_account/container/object?
temp_url_sig=da39a3ee5e6b4b0d3255bfef95601890afd80709&
temp_url_expires=1323479485&inline&filename=My+Test+File.pdf

XProfile¶

Profiling middleware for Swift Servers.

The current implementation is based on eventlet aware profiler.(For the future, more profilers could be added in to collect more data for analysis.) Profiling all incoming requests and accumulating cpu timing statistics information for performance tuning and optimization. An mini web UI is also provided for profiling data analysis. It can be accessed from the URL as below.

Index page for browse profile data:

http://SERVER_IP:PORT/__profile__

List all profiles to return profile ids in json format:

http://SERVER_IP:PORT/__profile__/
http://SERVER_IP:PORT/__profile__/all

Retrieve specific profile data in different formats:

http://SERVER_IP:PORT/__profile__/PROFILE_ID?format=[default|json|csv|ods]
http://SERVER_IP:PORT/__profile__/current?format=[default|json|csv|ods]
http://SERVER_IP:PORT/__profile__/all?format=[default|json|csv|ods]

Retrieve metrics from specific function in json format:

http://SERVER_IP:PORT/__profile__/PROFILE_ID/NFL?format=json
http://SERVER_IP:PORT/__profile__/current/NFL?format=json
http://SERVER_IP:PORT/__profile__/all/NFL?format=json

NFL is defined by concatenation of file name, function name and the first
line number.
e.g.::
    account.py:50(GETorHEAD)
or with full path:
    opt/stack/swift/swift/proxy/controllers/account.py:50(GETorHEAD)

A list of URL examples:

http://localhost:8080/__profile__    (proxy server)
http://localhost:6200/__profile__/all    (object server)
http://localhost:6201/__profile__/current    (container server)
http://localhost:6202/__profile__/12345?format=json    (account server)

The profiling middleware can be configured in paste file for WSGI servers such as proxy, account, container and object servers. Please refer to the sample configuration files in etc directory.

The profiling data is provided with four formats such as binary(by default), json, csv and odf spreadsheet which requires installing odfpy library:

sudo pip install odfpy

There’s also a simple visualization capability which is enabled by using matplotlib toolkit. it is also required to be installed if you want to use it to visualize statistic data:

sudo apt-get install python-matplotlib