> 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 are a bit of a
work in progress), 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 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