[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)

[Sam Johnston]

On Fri, Apr 17, 2009 at 2:07 PM, Richard Davies <
richard.davies at elastichosts.com> wrote:

> > storage:
>
> Tackling storage alone next, aside from CRUD, I believe the core verbs are:
>
> - resize (might or might not be via updating the size attribute, as per
>  other discussions this morning)


I don't have a problem so much with this being an update... ditto for
memory, cores etc. as if there's an obvious problem you'll return an error
(and it is, after all, idempotent). Even if the actual filesystem, memory
balloon driver, etc. takes a while to do it, you know straight away if the
allocation is successful.


> - read and write (to actually get data into and out of the storage from
>  outside the cloud)


For this (extension) I think we need to at least support basic HTTP based
transfers (bearing in mind resumable http
requests<http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal>are
a bit of a work
in progress<http://startupmeme.com/google-gears-lets-you-upload-youtube-videos-upto-1-gb/>),
but that we should also provide for some innovation. For example I should be
able to rsync the raw block device of a physical server to the cloud from
cron, create a storage resource pointing at this now-existing file and
switch to it in the case of a disaster.

I've listed some other ideas in the wiki too. WebDAV for example has native
support in systems like Windows and Mac OS X for some time now... being able
to "mount" the cloud (without SMB/CIFS) and drag e.g. an ISO image onto it
would be great for usability.


> - image (to copy data between storage areas within the cloud)
>

This gets interesting - it's something I was coming up against with
cush<http://code.google.com/p/cush/>last year... how do you tell a
server that you want one URL to be copied to
another, without sending the contents of that URL (which could be many
gigabytes) via the client (which could be a 3G iPhone).

Things are easier if everything's a URL because you can just create the
resource and let the infrastructure take care of retrieving and caching it
locally... but the semantics still needs to make sense.


> The other operations are all interesting, but secondary (I assume the point
> of taking storage offline would be that it is billed at a lower rate?)
>
> > *- start (aka online)
> > *- stop (aka offline)
> > *- snapshot?
> > *- backup?
>
> Thinking about the various current clouds, snapshots are probably the most
> common of these three. The snapshot operation will presumably create a new
> storage object, snapshotted from the first at the point of creation (likely
> copy on write).
>

Sure, snapshot's easy... you just have a "snapshot" actuator which returns a
new resource (complete with a pointer to the "live" version).


> This snapshot operation could be either a verb in itself, or alternatively
> that you pass the 'parent' to snapshot into the create call when you make
> the new storage object.
>

Interesting idea. To me a snapshot is something you do to an existing
device. So is a "copy".

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/3c8c881d/attachment.html