Commit 64cf8410 authored by Constantinos Venetsanopoulos's avatar Constantinos Venetsanopoulos
Browse files

docs: replace "Pithos+" with "Pithos"

parent 7f0a0dfc
......@@ -1121,13 +1121,13 @@ If the container ``images`` does not exist, create it:
$ kamaki file create images
You are now ready to upload an image to container ``images``. You can upload it
with a Pithos+ client, or use kamaki directly:
with a Pithos client, or use kamaki directly:
.. code-block:: console
$ kamaki file upload ubuntu.iso images
You can use any Pithos+ client to verify that the image was uploaded correctly,
You can use any Pithos client to verify that the image was uploaded correctly,
or you can list the contents of the container with kamaki:
.. code-block:: console
......@@ -1141,7 +1141,7 @@ unique user id (uuid).
Register Image
--------------
To register an image you will need to use the full Pithos+ URL. To register as
To register an image you will need to use the full Pithos URL. To register as
a public image the one from the previous example use:
.. code-block:: console
......
......@@ -46,7 +46,7 @@ Example reply:
[{"url": "/", "icon": "home-icon.png", "name": "grnet cloud", "id": "1"},
{"url": "/okeanos.html", "name": "~okeanos", "id": "2"},
{"url": "/ui/", "name": "pithos+", "id": "3"}]
{"url": "/ui/", "name": "pithos", "id": "3"}]
Get Menu
......
......@@ -40,7 +40,7 @@ Overview
Astakos service co-ordinates the access to resources (and the subsequent
permission model) and acts as the single point of registry and entry to the
GRNET cloud offering, comprising of Cyclades and Pithos+ subsystems.
GRNET cloud offering, comprising of Cyclades and Pithos subsystems.
It also propagates the user state to the Aquarium pricing subsystem.
......@@ -87,7 +87,7 @@ Authentication Use Cases
Cloud service user
~~~~~~~~~~~~~~~~~~
Alice requests a specific resource from a cloud service ex. Pithos+. In the
Alice requests a specific resource from a cloud service ex. Pithos. In the
request supplies the `X-Auth-Token` to identify whether she is eligible to
perform the specific task. The service contacts Astakos through its
``/astakos/api/authenticate`` api call (see :ref:`authenticate-api-label`)
......@@ -139,7 +139,7 @@ In case there are later approval terms that the user has not signed, the ``signe
Service Registration
--------------------
Services (ex. cyclades, pithos+) are registered in astakos via ``snf-manage registerservice``. This command generates and prints a service token useful for accessing the service API.
Services (ex. Cyclades, Pithos) are registered in astakos via ``snf-manage registerservice``. This command generates and prints a service token useful for accessing the service API.
Registered services can be viewed by ``snf-manage showservices`` command and ``snf-manage unregisterservice`` can be used to unregister a service.
.. _authentication-label:
......
......@@ -4,13 +4,13 @@ snf-tools (0.13.0)
* Add more tests for Images
- Download image from pithos+
- Upload and register image
* Add tests for Pithos+
* Add tests for Pithos
- Test container list actually returns containers
- Test if containers have unique names
- Create e new container
- Upload something to pithos+
- Download something from pithos+
- Remove files/containers from pithos+
- Upload something to Pithos
- Download something from Pithos
- Remove files/containers from Pithos
* Add two (mandatory) flags
- `--pithos' for specifing pithos url
- `--astakos' for specifing astakos url
......
Pithos+ API
===========
Pithos API
==========
Introduction
------------
......
Object Storage Service (Pithos+)
================================
Object Storage Service (Pithos)
===============================
Pithos+ is an online storage service based on the OpenStack Object
Pithos is an online storage service based on the OpenStack Object
Storage API with several important extensions. It uses a
block-based mechanism to allow users to upload, download, and share
files, keep different versions of a file, and attach policies to them.
It follows a layered, modular implementation. Pithos+ was designed to
It follows a layered, modular implementation. Pithos was designed to
be used as a storage service by the total set of the Greek research
and academic community (counting tens of thousands of users) but is
free and open to use by anybody, under a BSD-2 clause license.
A presentation of Pithos+ features and architecture is :download:`here <pithos-plus.pdf>`.
A presentation of Pithos features and architecture is :download:`here <pithos-plus.pdf>`.
Introduction
------------
......@@ -22,7 +22,7 @@ and was made available in spring 2009. It now has more than
12,000 users.
In 2011 GRNET decided to offer a new, evolved online storage
service, to be called Pithos+. Pithos+ is designed to address the
service, to be called Pithos. Pithos is designed to address the
main requirements expressed by the Pithos users in the first two years of
operation:
......@@ -45,21 +45,21 @@ operation:
open up Pithos to non-Shibboleth authenticated users as well.
* Use open standards as far as possible.
In what follows we describe the main features of Pithos+, the elements
In what follows we describe the main features of Pithos, the elements
of its design and the capabilities it affords. We touch on related
work and we provide some discussion on our experiences and thoughts on
the future.
Pithos+ Features
----------------
Pithos Features
---------------
Pithos+ is based on the OpenStack Object Storage API (Pithos
Pithos is based on the OpenStack Object Storage API (Pithos
used a home-grown API). We decided to adopt an open standard
API in order to leverage existing clients that implement the
API. In this way, a user can access Pithos+ with a standard
OpenStack client - although users will want to use a Pithos+ client to
API. In this way, a user can access Pithos with a standard
OpenStack client - although users will want to use a Pithos client to
use features going beyond those offered by the OpenStack API.
The strategy paid off during Pithos+ development itself, as we were
The strategy paid off during Pithos development itself, as we were
able to access and test the service with existing clients, while also
developing new clients based on open source OpenStack clients.
......@@ -69,10 +69,10 @@ The major extensions on the OpenStack API are:
OpenStack stores objects, which may be files, but this is not
necessary - large files (longer than 5GBytes), for instance, must be
stored as a series of distinct objects accompanied by a manifest.
Pithos+ stores blocks, so objects can be of unlimited size.
Pithos stores blocks, so objects can be of unlimited size.
* Permissions on individual files and folders. Note that folders
do not exist in the OpenStack API, but are simulated by
appropriate conventions, an approach we have kept in Pithos+ to
appropriate conventions, an approach we have kept in Pithos to
avoid incompatibility.
* Fully-versioned objects.
* Metadata-based queries. Users are free to set metadata on their
......@@ -84,25 +84,25 @@ The major extensions on the OpenStack API are:
* Partial upload and download based on HTTP request
headers and parameters.
* Object updates, where data may even come from other objects
already stored in Pithos+. This allows users to compose objects from
already stored in Pithos. This allows users to compose objects from
other objects without uploading data.
* All objects are assigned UUIDs on creation, which can be
used to reference them regardless of their path location.
Pithos+ Design
--------------
Pithos Design
-------------
Pithos+ is built on a layered architecture (see Figure).
The Pithos+ server speaks HTTP with the outside world. The HTTP
Pithos is built on a layered architecture (see Figure).
The Pithos server speaks HTTP with the outside world. The HTTP
operations implement an extended OpenStack Object Storage API.
The back end is a library meant to be used by internal code and
other front ends. For instance, the back end library, apart from being
used in Pithos+ for implementing the OpenStack Object Storage API,
used in Pithos for implementing the OpenStack Object Storage API,
is also used in our implementation of the OpenStack Image
Service API. Moreover, the back end library allows specification
of different namespaces for metadata, so that the same object can be
viewed by different front end APIs with different sets of
metadata. Hence the same object can be viewed as a file in Pithos+,
metadata. Hence the same object can be viewed as a file in Pithos,
with one set of metadata, or as an image with a different set of
metadata, in our implementation of the OpenStack Image Service.
......@@ -118,13 +118,13 @@ evaluating RADOS - http://ceph.newdream.net/category/rados), and metadata to a N
Block-based Storage for the Client
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since an object is saved as a set of blocks in Pithos+, object
Since an object is saved as a set of blocks in Pithos, object
operations are no longer required to refer to the whole object. We can
handle parts of objects as needed when uploading, downloading, or
copying and moving data.
In particular, a client, provided it has access permissions, can
download data from Pithos+ by issuing a ``GET`` request on an
download data from Pithos by issuing a ``GET`` request on an
object. If the request includes the ``hashmap`` parameter, then the
request refers to a hashmap, that is, a set containing the
object's block hashes. The reply is of the form::
......@@ -142,7 +142,7 @@ checked against the ``X-Object-Hash`` header, returned by the
server and containing the root Merkle hash of the object's
hashmap.
When uploading a file to Pithos+, only the missing blocks will be
When uploading a file to Pithos, only the missing blocks will be
submitted to the server, with the following algorithm:
* Calculate the hash value for each block of the object to be
......@@ -162,14 +162,14 @@ submitted to the server, with the following algorithm:
In effect, we are deduplicating data based on their block hashes,
transparently to the users. This results to perceived instantaneous
uploads when material is already present in Pithos+ storage.
uploads when material is already present in Pithos storage.
Block-based Storage Processing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hashmaps themselves are saved in blocks. All blocks are persisted to
storage using content-based addressing. It follows that to read a
file, Pithos+ performs the following operations:
file, Pithos performs the following operations:
* The client issues a request to get a file, via HTTP ``GET``.
* The API front end asks from the back end the metadata
......@@ -227,10 +227,10 @@ possible to pass a parameter to HTTP ``POST`` to specify that the
data will come from another object, instead of being uploaded by the
client.
Pithos+ Back End Nodes
^^^^^^^^^^^^^^^^^^^^^^
Pithos Back End Nodes
^^^^^^^^^^^^^^^^^^^^^
Pithos+ organizes entities in a tree hierarchy, with one tree node per
Pithos organizes entities in a tree hierarchy, with one tree node per
path entry (see Figure). Nodes can be accounts,
containers, and objects. A user may have multiple
accounts, each account may have multiple containers, and each
......@@ -246,13 +246,13 @@ The notion of folders or directories is through conventions that
simulate pseudo-hierarchical folders. In particular, object names that
contain the forward slash character and have an accompanying marker
object with a ``Content-Type: application/directory`` as part of
their metadata can be treated as directories by Pithos+ clients. Each
their metadata can be treated as directories by Pithos clients. Each
node corresponds to a unique path, and we keep its parent in the
account/container/object hierarchy (that is, all objects have a
container as their parent).
Pithos+ Back End Versions
^^^^^^^^^^^^^^^^^^^^^^^^^
Pithos Back End Versions
^^^^^^^^^^^^^^^^^^^^^^^^
For each object version we keep the root Merkle hash of the object it
refers to, the size of the object, the last modification time and the
......@@ -265,25 +265,25 @@ to one of the following three clusters (see Figure):
.. image:: images/pithos-backend-versions.png
This versioning allows Pithos+ to offer to its user time-based
This versioning allows Pithos to offer to its user time-based
contents listing of their accounts. In effect, this also allows them
to take their containers back in time. This is implemented
conceptually by taking a vertical line in the Figure and
presenting to the user the state on the left side of the line.
Pithos+ Back End Permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pithos Back End Permissions
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pithos+ recognizes read and write permissions, which can be granted to
Pithos recognizes read and write permissions, which can be granted to
individual users or groups of users. Groups as collections of users
created at the account level by users themselves, and are flat - a
group cannot contain or reference another group. Ownership of a file
cannot be delegated.
Pithos+ also recognizes a "public" permission, which means that the
Pithos also recognizes a "public" permission, which means that the
object is readable by all. When an object is made public, it is
assigned a URL that can be used to access the object from
outside Pithos+ even by non-Pithos+ users.
outside Pithos even by non-Pithos users.
Permissions can be assigned to objects, which may be actual files, or
directories. When listing objects, the back end uses the permissions as
......@@ -310,7 +310,7 @@ OpenStack, while offering additional capabilities.
Discussion
----------
Pithos+ is implemented in Python as a Django application. We use SQLAlchemy
Pithos is implemented in Python as a Django application. We use SQLAlchemy
as a database abstraction layer. It is currently about
17,000 lines of code, and it has taken about 50 person months of
development effort. This development was done from scratch, with no
......@@ -328,20 +328,20 @@ different operating systems (MS-Windows, Mac OS X, Android, and iOS).
The desktop clients allow synchronization with local directories, a
feature that existing users of Pithos have been asking for, probably
influenced by services like DropBox. These clients are offered in
parallel to the standard Pithos+ interface, which is a web application
parallel to the standard Pithos interface, which is a web application
build on top of the API front end - we treat our own web
application as just another client that has to go through the API
front end, without granting it access to the back end directly.
We are carrying the idea of our own services being clients to Pithos+
We are carrying the idea of our own services being clients to Pithos
a step further, with new projects we have in our pipeline, in which a
digital repository service will be built on top of Pithos+. It will
digital repository service will be built on top of Pithos. It will
use again the API front end, so that repository users will have
all Pithos+ capabilities, and on top of them we will build additional
all Pithos capabilities, and on top of them we will build additional
functionality such as full text search, Dublin Core metadata storage
and querying, streaming, and so on.
At the time of this writing (March 2012) Pithos+ is in alpha,
At the time of this writing (March 2012) Pithos is in alpha,
available to users by invitation. We will extend our user base as we
move to beta in the coming months, and to our full set of users in the
second half of 2012. We are eager to see how our ideas fare as we will
......@@ -350,14 +350,14 @@ scaling up, and we welcome any comments and suggestions.
Acknowledgments
---------------
Pithos+ is financially supported by Grant 296114, "Advanced Computing
Pithos is financially supported by Grant 296114, "Advanced Computing
Services for the Research and Academic Community", of the Greek
National Strategic Reference Framework.
Availability
------------
The Pithos+ code is available under a BSD 2-clause license from:
The Pithos code is available under a BSD 2-clause license from:
https://code.grnet.gr/projects/pithos/repository
The code can also be accessed from its source repository:
......
......@@ -172,9 +172,9 @@ Name Description Image Glance
================ ===================== ======== ======
id A unique image id ✔ **✘**
uri Unique id in URI form **✘** ✔
location Pithos+ file location ✔ **✘**
location Pithos file location ✔ **✘**
name The name of the image ✔ ✔
status ???The VM status??? ✔ **✘**
status The Image status ✔ **✘**
disk_format The disc format ✔ ✔
container_format The container format ✔ ✔
size Image size in bytes ✔ ✔
......@@ -236,8 +236,8 @@ According to the Synnefo approach, this request performs two operations:
* commits metadata for the new image
* update the metadata of an existing image
The physical image file must be uploaded on a `Pithos+ <pithos.html>`_ server,
at a space accessible by the user. The Pithos+ location of the physical file
The physical image file must be uploaded on a `Pithos <pithos.html>`_ server,
at a space accessible by the user. The Pithos location of the physical file
acts as a key for the image (image ids and image locations are uniquely
coupled).
......@@ -323,7 +323,7 @@ X-Image-Meta-Disk-Format Disk format ✔ **✘**
X-Image-Meta-Container-Format Container format ✔ **✘**
X-Image-Meta-Size Img file size ✔ **✘**
X-Image-Meta-Checksum Img file MD5 checksum ✔ **✘**
X-Image-Meta-Location Pithos+ file location ✔ **✘**
X-Image-Meta-Location Pithos file location ✔ **✘**
X-Image-Meta-Created-At Date of img creation ✔ **✘**
X-Image-Meta-Deleted-At Date of img deletion ✔ **✘**
X-Image-Meta-Status Img status ✔ **✘**
......@@ -412,7 +412,7 @@ X-Image-Meta-Disk-Format Disk format
X-Image-Meta-Container-Format Container format
X-Image-Meta-Size Img file size
X-Image-Meta-Checksum Img file MD5 checksum
X-Image-Meta-Location Pithos+ file location
X-Image-Meta-Location Pithos file location
X-Image-Meta-Created-At Date of img creation
X-Image-Meta-Deleted-At Date of img deletion
X-Image-Meta-Status Img status
......@@ -469,7 +469,7 @@ Return Code Description
Response Header Description Image Glance
============================= ===================== ======== ======
X-Image-Meta-Id Unique img id ✔ ✔
X-Image-Meta-Location Pithos+ file location ✔ **✘**
X-Image-Meta-Location Pithos file location ✔ **✘**
X-Image-Meta-URI URI of image file **✘** ✔
X-Image-Meta-Name Img name ✔ ✔
X-Image-Meta-Disk-Format Disk format ✔ **✘**
......@@ -814,8 +814,8 @@ Can be provided by user **✘** ✔
.. _location-ref:
Image File Location at a Pithos+ Server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Image File Location at a Pithos Server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To refer to a pithos location file, use the following format::
......
This diff is collapsed.
......@@ -15,7 +15,7 @@ install``, and assumes the nodes run Debian Squeeze. After successful
installation, you will have the following services running:
* Identity Management (Astakos)
* Object Storage Service (Pithos+)
* Object Storage Service (Pithos)
* Compute Service (Cyclades)
* Image Service (part of Cyclades)
* Network Service (part of Cyclades)
......@@ -25,8 +25,8 @@ and a single unified Web UI to manage them all.
The Volume Storage Service (Archipelago) and the Billing Service (Aquarium) are
not released yet.
If you just want to install the Object Storage Service (Pithos+), follow the guide
and just stop after the "Testing of Pithos+" section.
If you just want to install the Object Storage Service (Pithos), follow the guide
and just stop after the "Testing of Pithos" section.
Building a dev environment
--------------------------
......
......@@ -82,7 +82,7 @@ Then initialize the Database and register services with:
# snf-manage loaddata groups
# snf-manage service-add "home" https://cms.example.com/ home-icon.png
# snf-manage service-add "cyclades" https://cyclades.example.com/ui/
# snf-manage service-add "pithos+" https://pithos.example.com/ui/
# snf-manage service-add "pithos" https://pithos.example.com/ui/
# snf-manage astakos-init --load-service-resources
# snf-manage quota --sync
# /etc/init.d/gunicorn restart
......
......@@ -42,7 +42,7 @@ privileges on the database. We do this by running:
postgres=# CREATE USER synnefo WITH PASSWORD 'example_passw0rd';
postgres=# GRANT ALL PRIVILEGES ON DATABASE snf_apps TO synnefo;
We also create the database ``snf_pithos`` needed by the pithos+ backend and
We also create the database ``snf_pithos`` needed by the Pithos backend and
grant the ``synnefo`` user all privileges on the database.
.. code-block:: console
......
......@@ -90,7 +90,7 @@ In `/etc/synnefo/webclient.conf` add:
PITHOS_UI_FEEDBACK_URL = "/feedback"
XXXXXXXXXXXXXX should be the Pithos+ token and id found on astakos node by running:
XXXXXXXXXXXXXX should be the Pithos token and id found on astakos node by running:
.. code-block:: console
......
......@@ -24,7 +24,7 @@ order to have full synnefo funtionality. After successful installation, you
will have the following services running:
* Identity Management (Astakos)
* Object Storage Service (Pithos+)
* Object Storage Service (Pithos)
* Compute Service (Cyclades)
* Image Service (part of Cyclades)
* Network Service (part of Cyclades)
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment