Docs: Lack of OpenStack storage concepts explanation

[Alexey Eromenko]

The problem:
I'm new to OpenStack and while learning it, many of it's concepts seem alien.

I did read start guide PDF (Nova), the Install Guide (Nova) and parts of the Admin Guide (Nova).
 (from docs.openstack.org), but it doesn't explain the most basic concepts.

Things like:
1. Object Storage (swift) vs. Network File System (NFS)
=============================================
Why SWIFT ?

According to: "notmyname"
<notmyname> technologov: the things that object storage in general
(and swift specifically) provides is large scale, cheap, and durable
storage

<notmyname> technologov: object storage is all about relaxing some of
the constraints of a posix-style system. for example, if you don't
have to provide atomic operations (ie you can rely on eventual
consistency), you can much more easily scale a storage system and not
have a central point of failure

Also:
I have seen a video, that explains a bit about hashing searches, but
very incomplete.
Also what happens if new servers get added or removed ?
Such concepts need to be added into the docs.

Does Object Storage also stores files ? (seems yes)

How is SWIFT coherent ? Or it does not guarantee coherency ?

2. Nova-volume vs Nova-object vs Images (glance) vs. Object Storage (swift)
=============================================

Both (1) Nova-volume and (2) Nova-object and (3) glance and (4) swift seem capable of
storing VM hard disks.
What's the conceptual difference between the three ?

Possible Answer:
"<notmyname> technologov: nova-volume is for block storage attached to
a VM. glance is to manage the VM images in a nova cluster and provide
nice ways of storing them (a bridge to the storage, not the storage
itself). swift is an object storage system that can be used by glance
or on its own. swift isn't a filesystem, so it's not "mountable" like
the devices managed with nova-volume"

Arguments & Discussion:
<technologov> come on... "mountable" term is a joke... nowadays you
can mount GMail or Wikipedia... via FUSE
<technologov> w.p. is not a Filesystem either :)

<notmyname> ok, so you don't use swift like a traditional hard drive.
the only access to it is API-based (and the API is http)
<notmyname> that can be wrapped into a FUSE filesystem (but there are
big tradeoffs in doing so--advantages too, of course)

Once we can agree on the concepts, need to patch official docs.

=======================================================
Some users say this is like Amazon AWS or Amazon S3 or whatever...

the problem is: I have never used Amazon. I have used RHEV (Red Hat Enterprise Virtualization), which is based on local storage or NFS or iSCSI concepts... All the "object storage" concepts are 100% brand new to me.

We need to define the concepts, and make sure they are understandable for all users alike from different backgrounds.

-Technologov, 22.02.2012.

[Alexey Eromenko (al4321)]

A *huge* addition to the information picture was found:
http://blog.wikimedia.org/2012/02/09/scaling-media-storage-at-wikimedia-with-swift/
http://wikitech.wikimedia.org/view/Media_server/Distributed_File_Storage_choices

1. many replication / stability details are now visible.

2. swift can be used as a standalone storage, without "nova" / computing component. This is very important part of the information puzzle.

-Technologov

[Tom Fifield (fifieldt)]

https://review.openstack.org/#/c/7613/ is related to this

[Tom Fifield (fifieldt)]

Here's some reworking of the text:

Object Storage in general (and swift specifically) provides large scale, cheap, and durable
storage. Swift is not used like a traditional hard drive - Object storage is all about
relaxing some of the constraints of a POSIX-style file system. The access to it is API-based (and the API uses http).

This is a good idea as if you don't have to provide atomic operations (ie you can rely on eventual
consistency), you can much more easily scale a storage system and avoid a central point of failure.

 The OpenStack Image Service is used to manage the virtual machine images in an OpenStack compute cluster
 and provide an abstraction to ways of storing them (a bridge to the storage, not the storage itself).
 Swift is one option that can be used by the OpenStack Image Service to store images, but it can function
 on its own.

nova-volume is for block storage attached to a virtual machine. Where Swift isn't a filesystm,
nova-volume is - designed to provide "mountable" devices.

[eternaltyro (eternaltyro)]

Tom, I'll add that text with a few modifications to the code.. Alexy, those links were helpful. Thanks.

[Tom Fifield (fifieldt)]

Hi Yogesh,

Did you end up adding those edits? It'd be great to get them in before folsom lands :D

[eternaltyro (eternaltyro)]

Tom,

I'm on it. Been busy with other stuff. I'll try and get it done before Folsom lands. BTW, here's something that might make the picture a bit more clear: http://greg.brim.net/page/building_a_consistent_hashing_ring.html

--
Yogesh.

[Tom Fifield (fifieldt)]

Thanks Yogesh!

[Tom Fifield (fifieldt)]

Hi Yogesh,

4 days to go - did you commit yet? Need a hand?

[eternaltyro (eternaltyro)]

https://etherpad.openstack.org/Openstack_Concepts

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/18799

[Tom Fifield (fifieldt)]

https://review.openstack.org/#/c/18799/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/18799
Committed: http://github.com/openstack/openstack-manuals/commit/2597384424ede0694a2d4415f8f9a073c9e73e28
Submitter: Jenkins
Branch: master

commit 2597384424ede0694a2d4415f8f9a073c9e73e28
Author: Tom Fifield <email address hidden>
Date: Wed Jan 2 12:16:11 2013 +1100

    Adds a storage concepts explanation

    fixes bug 938365

    There was a lack of storage concepts in the early parts of the
    documentation. This adds a new section with a kick-start table
    to allow first time readers to quickly understand the different
    types of storage in an OpenStack installation.

    Just a few edits -- double-check the ephemeral explanation as
    I took it from the aboutcompute.xml file.

    Change-Id: I447423f98bc3e36b6018179cdd81d8bb6d56b221