Files
572b6be8f254872b05993bb96306b488fa4d97f1
swift /README.rst

161 lines
5.7 KiB
ReStructuredText
Raw Normal View History

========================
Team and repository tags
========================
.. image:: https://governance.openstack.org/tc/badges/swift.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html
.. Change things from this point on
Swift
=====
A distributed object storage system designed to scale from a single
machine to thousands of servers. Swift is optimized for multi-tenancy
and high concurrency. Swift is ideal for backups, web and mobile
content, and any other unstructured data that can grow without bound.
Swift provides a simple, REST-based API fully documented at
https://docs.openstack.org/.
Swift was originally developed as the basis for Rackspace's Cloud Files
and was open-sourced in 2010 as part of the OpenStack project. It has
since grown to include contributions from many companies and has spawned
a thriving ecosystem of 3rd party tools. Swift's contributors are listed
in the AUTHORS file.
Docs
----
To build documentation install sphinx (``pip install sphinx``), run
``python setup.py build_sphinx``, and then browse to
/doc/build/html/index.html. These docs are auto-generated after every
commit and available online at
https://docs.openstack.org/swift/latest/.
For Developers
--------------
Getting Started
~~~~~~~~~~~~~~~
Swift is part of OpenStack and follows the code contribution, review, and
testing processes common to all OpenStack projects.
If you would like to start contributing, check out these
`notes <CONTRIBUTING.rst>`__ to help you get started.
The best place to get started is the
`"SAIO - Swift All In One" <https://docs.openstack.org/swift/latest/development_saio.html>`__.
This document will walk you through setting up a development cluster of
Swift in a VM. The SAIO environment is ideal for running small-scale
tests against swift and trying out new features and bug fixes.
Tests
~~~~~
There are three types of tests included in Swift's source tree.
#. Unit tests
#. Functional tests
#. Probe tests
Unit tests check that small sections of the code behave properly. For example,
a unit test may test a single function to ensure that various input gives the
expected output. This validates that the code is correct and regressions are
not introduced.
Functional tests check that the client API is working as expected. These can
be run against any endpoint claiming to support the Swift API (although some
tests require multiple accounts with different privilege levels). These are
"black box" tests that ensure that client apps written against Swift will
continue to work.
Probe tests are "white box" tests that validate the internal workings of a
Swift cluster. They are written to work against the
`"SAIO - Swift All In One" <https://docs.openstack.org/swift/latest/development_saio.html>`__
dev environment. For example, a probe test may create an object, delete one
replica, and ensure that the background consistency processes find and correct
the error.
You can run unit tests with ``.unittests``, functional tests with
``.functests``, and probe tests with ``.probetests``. There is an
additional ``.alltests`` script that wraps the other three.
Add checksum to object extended attributes Currently, our integrity checking for objects is pretty weak when it comes to object metadata. If the extended attributes on a .data or .meta file get corrupted in such a way that we can still unpickle it, we don't have anything that detects that. This could be especially bad with encrypted etags; if the encrypted etag (X-Object-Sysmeta-Crypto-Etag or whatever it is) gets some bits flipped, then we'll cheerfully decrypt the cipherjunk into plainjunk, then send it to the client. Net effect is that the client sees a GET response with an ETag that doesn't match the MD5 of the object *and* Swift has no way of detecting and quarantining this object. Note that, with an unencrypted object, if the ETag metadatum gets mangled, then the object will be quarantined by the object server or auditor, whichever notices first. As part of this commit, I also ripped out some mocking of getxattr/setxattr in tests. It appears to be there to allow unit tests to run on systems where /tmp doesn't support xattrs. However, since the mock is keyed off of inode number and inode numbers get re-used, there's lots of leakage between different test runs. On a real FS, unlinking a file and then creating a new one of the same name will also reset the xattrs; this isn't the case with the mock. The mock was pretty old; Ubuntu 12.04 and up all support xattrs in /tmp, and recent Red Hat / CentOS releases do too. The xattr mock was added in 2011; maybe it was to support Ubuntu Lucid Lynx? Bonus: now you can pause a test with the debugger, inspect its files in /tmp, and actually see the xattrs along with the data. Since this patch now uses a real filesystem for testing filesystem operations, tests are skipped if the underlying filesystem does not support setting xattrs (eg tmpfs or more than 4k of xattrs on ext4). References to "/tmp" have been replaced with calls to tempfile.gettempdir(). This will allow setting the TMPDIR envvar in test setup and getting an XFS filesystem instead of ext4 or tmpfs. THIS PATCH SIGNIFICANTLY CHANGES TESTING ENVIRONMENTS With this patch, every test environment will require TMPDIR to be using a filesystem that supports at least 4k of extended attributes. Neither ext4 nor tempfs support this. XFS is recommended. So why all the SkipTests? Why not simply raise an error? We still need the tests to run on the base image for OpenStack's CI system. Since we were previously mocking out xattr, there wasn't a problem, but we also weren't actually testing anything. This patch adds functionality to validate xattr data, so we need to drop the mock. `test.unit.skip_if_no_xattrs()` is also imported into `test.functional` so that functional tests can import it from the functional test namespace. The related OpenStack CI infrastructure changes are made in https://review.openstack.org/#/c/394600/. Co-Authored-By: John Dickinson <me@not.mn> Change-Id: I98a37c0d451f4960b7a12f648e4405c6c6716808
2016年06月30日 16:52:58 -07:00
To fully run the tests, the target environment must use a filesystem that
supports large xattrs. XFS is strongly recommended. For unit tests and in-
process functional tests, either mount ``/tmp`` with XFS or provide another
XFS filesystem via the ``TMPDIR`` environment variable. Without this setting,
tests should still pass, but a very large number will be skipped.
Code Organization
~~~~~~~~~~~~~~~~~
- bin/: Executable scripts that are the processes run by the deployer
- doc/: Documentation
- etc/: Sample config files
- examples/: Config snippets used in the docs
- swift/: Core code
- account/: account server
- cli/: code that backs some of the CLI tools in bin/
- common/: code shared by different modules
- middleware/: "standard", officially-supported middleware
- ring/: code implementing Swift's ring
- container/: container server
- locale/: internationalization (translation) data
- obj/: object server
- proxy/: proxy server
- test/: Unit, functional, and probe tests
Data Flow
~~~~~~~~~
Swift is a WSGI application and uses eventlet's WSGI server. After the
processes are running, the entry point for new requests is the
``Application`` class in ``swift/proxy/server.py``. From there, a
controller is chosen, and the request is processed. The proxy may choose
to forward the request to a back-end server. For example, the entry
point for requests to the object server is the ``ObjectController``
class in ``swift/obj/server.py``.
For Deployers
-------------
Deployer docs are also available at
https://docs.openstack.org/swift/latest/. A good starting point is at
https://docs.openstack.org/swift/latest/deployment_guide.html
There is an `ops runbook <https://docs.openstack.org/swift/latest/ops_runbook/index.html>`__
that gives information about how to diagnose and troubleshoot common issues
when running a Swift cluster.
You can run functional tests against a swift cluster with
``.functests``. These functional tests require ``/etc/swift/test.conf``
to run. A sample config file can be found in this source tree in
``test/sample.conf``.
For Client Apps
---------------
For client applications, official Python language bindings are provided
at https://github.com/openstack/python-swiftclient.
Complete API documentation at
https://developer.openstack.org/api-ref/object-store/
There is a large ecosystem of applications and libraries that support and
work with OpenStack Swift. Several are listed on the
`associated projects <https://docs.openstack.org/swift/latest/associated_projects.html>`__
page.
--------------
For more information come hang out in #openstack-swift on freenode.
Thanks,
The Swift Development Team