Swift Documentation

Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply. This documentation is generated by the Sphinx toolkit and lives in the source tree. Additional documentation on Swift and other components of OpenStack can be found on the OpenStack wiki and at http://docs.openstack.org.

Note: If youre looking for associated projects that enhance or use Swift, please see the Associated Projects page.

Chapter One – Getting Started

1.1 System Requirements 

Swift development currently targets Ubuntu Server 16.04, but should work on most Linux platforms. Swift is written in Python and has these dependencies:

• Python (2.7 or 3.6-3.9)
• rsync 3.x
• iberasurecode
• The Python packages listed in the requirements file
• Testing additionally requires the test dependencies
• Testing requires these distribution packages

1.2 Development 

To get started with development with Swift, or to just play around, the following docs will be useful:

• Swift All in One – Set up a VM with Swift installed
• Development Guidelines
• First Contribution to Swift
• Associated Projects

1.3 CLI client and SDK library 

There are many clients in the ecosystem. The official CLI and SDK is python-swiftclient.

• Source code
• Python Package Index

1.4 Production 

If you want to set up and configure Swift for a production cluster, the following doc should be useful:

• Multiple Server Swift Installation

Chapter Two – Overview And Concepts

2.1 Object Storage API overview 

OpenStack Object Storage is a highly available, distributed, eventually consistent object/blob store. You create, modify, and get objects and metadata by using the Object Storage API, which is implemented as a set of Representational State Transfer (REST) web services.

For an introduction to OpenStack Object Storage, see the OpenStack Swift Administrator Guide.

You use the HTTPS (SSL) protocol to interact with Object Storage, and you use standard HTTP calls to perform API operations. You can also use language-specific APIs, which use the RESTful API, that make it easier for you to integrate into your applications.

To assert your right to access and change data in an account, you identify yourself to Object Storage by us- ing an authentication token. To get a token, you present your credentials to an authentication service. The authentication service returns a token and the URL for the account. Depending on which authentication service that you use, the URL for the account appears in:

• OpenStack Identity Service. The URL is defined in the service catalog.
• Tempauth. The URL is provided in the X-Storage-Url response header.

In both cases, the URL is the full URL and includes the account resource.The Object Storage API supports the standard, non-serialized response format, which is the default, and both JSON and XML serialized response formats.

The Object Storage system organizes data in a hierarchy, as follows:

• Account. Represents the top-level of the hierarchy.
  Your service provider creates your account and you own all resources in that account. The ac- count defines a namespace for containers. A container might have the same name in two different accounts.
  In the OpenStack environment, account is synonymous with a project or tenant.
• Container. Defines a namespace for objects. An object with the same name in two different containers represents two different objects. You can create any number of containers within an account.
  In addition to containing objects, you can also use the container to control access to objects by using an access control list (ACL). You cannot store an ACL with individual objects.
  In addition, you configure and control many other features, such as object versioning, at the container level.
  You can bulk-delete up to 10,000 containers in a single request.
  You can set a storage policy on a container with predefined names and definitions from your cloud provider.
• Object. Stores data content, such as documents, images, and so on. You can also store custom metadata with an object.
  With the Object Storage API, you can:
  •  Store an unlimited number of objects. Each object can be as large as 5 GB, which is the default. You can configure the maximum object size.
  • Upload and store objects of any size with large object creation.
  • Use cross-origin resource sharing to manage object security.
  • Compress files using content-encoding metadata.
  • Override browser behavior for an object using content-disposition metadata.
  • Schedule objects for deletion.
  • Bulk-delete up to 10,000 objects in a single request.
  • Auto-extract archive files.
  • Generate a URL that provides time-limited GET access to an object.
  • Upload objects directly to the Object Storage system from a browser by using form POST middleware.
  • Create symbolic links to other objects.