Revision 8f9976c6 docs/pithos.rst
b/docs/pithos.rst | ||
---|---|---|
3 | 3 |
File Storage Service (pithos+) |
4 | 4 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
5 | 5 |
|
6 |
Pithos+ is the synnefo File Storage Service and implements the OpenStack Object Storage API + synnefo extensions. |
|
6 |
Pithos+ is the synnefo File Storage Service and implements the OpenStack Object |
|
7 |
Storage API + synnefo extensions. |
|
8 |
|
|
9 |
|
|
10 |
Introduction |
|
11 |
============ |
|
12 |
|
|
13 |
Pithos is a storage service implemented by GRNET (http://www.grnet.gr). Data is |
|
14 |
stored as objects, organized in containers, belonging to an account. This |
|
15 |
hierarchy of storage layers has been inspired by the OpenStack Object Storage |
|
16 |
(OOS) API and similar CloudFiles API by Rackspace. The Pithos API follows the |
|
17 |
OOS API as closely as possible. One of the design requirements has been to be |
|
18 |
able to use Pithos with clients built for the OOS, without changes. |
|
19 |
|
|
20 |
However, to be able to take full advantage of the Pithos infrastructure, client |
|
21 |
software should be aware of the extensions that differentiate Pithos from OOS. |
|
22 |
Pithos objects can be updated, or appended to. Pithos will store sharing |
|
23 |
permissions per object and enforce corresponding authorization policies. |
|
24 |
Automatic version management, allows taking account and container listings back |
|
25 |
in time, as well as reading previous instances of objects. |
|
26 |
|
|
27 |
The storage backend of Pithos is block oriented, permitting efficient, |
|
28 |
deduplicated data placement. The block structure of objects is exposed at the |
|
29 |
API layer, in order to encourage external software to implement advanced data |
|
30 |
management operations. |
|
31 |
|
|
32 |
|
|
33 |
Pithos Users and Authentication |
|
34 |
=============================== |
|
35 |
|
|
36 |
In Pithos, each user is uniquely identified by a token. All API requests |
|
37 |
require a token and each token is internally resolved to an account string. The |
|
38 |
API uses the account string to identify the user's own files, thus whether a |
|
39 |
request is local or cross-account. |
|
40 |
|
|
41 |
Pithos does not keep a user database. For development and testing purposes, |
|
42 |
user identifiers and their corresponding tokens can be defined in the settings |
|
43 |
file. However, Pithos is designed with an external authentication service in |
|
44 |
mind. This service must handle the details of validating user credentials and |
|
45 |
communicate with Pithos via a middleware software component that, given a |
|
46 |
token, fills in the internal request account variable. |
|
47 |
|
|
48 |
Client software using Pithos, if not already knowing a user's identifier and |
|
49 |
token, should forward to the ``/login`` URI. The Pithos server, depending on |
|
50 |
its configuration will redirect to the appropriate login page. |
|
51 |
|
|
52 |
The login URI accepts the following parameters: |
|
53 |
|
|
54 |
====================== ========================= |
|
55 |
Request Parameter Name Value |
|
56 |
====================== ========================= |
|
57 |
next The URI to redirect to when the process is finished |
|
58 |
renew Force token renewal (no value parameter) |
|
59 |
force Force logout current user (no value parameter) |
|
60 |
====================== ========================= |
|
61 |
|
|
62 |
When done with logging in, the service's login URI should redirect to the URI |
|
63 |
provided with ``next``, adding ``user`` and ``token`` parameters, which contain |
|
64 |
the account and token fields respectively. |
|
65 |
|
|
66 |
A user management service that implements a login URI according to these |
|
67 |
conventions is Astakos. |
|
68 |
|
|
7 | 69 |
|
8 | 70 |
Pithos+ Architecture |
9 | 71 |
==================== |
Also available in: Unified diff