Hi Jeff, comments in-line:
On 15/07/10 02:17, Jeff Darcy wrote:
On 01/-10/-28163 02:59 PM, [email protected] wrote:
I think there are two independent subtasks here:
**Work out the operations for the generic cloud storage (i.e.
s3/cloudfiles) and implement 'Blob Management'. This will appear as a
top level collection (like Instances, Images etc, 'Blobs' or somesuch
name 'Objects'?) - to appear obviously only for those drivers that
support it, Amazon AWS and Rackspace.
Also any cloud running the S3-compatible stack from Project Hail.
great, I was not aware of this project. Certainly it depends on what
'S3-compatible means' - in the longer term it would be easy to add
drivers for any cloud storage providers - we decided to get a rough
first cut with S3 and Cloudfiles for now since AWS EC3 and Rackspace
are the only currently implemented dcloud API drivers that allow (or
will 'soon' do so) the registration of an Object in (their own) cloud
storage service as a Server Image in their public cloud service.
> An image might be an object unto itself, or it
might be a reference (named or unnamed) to another object (block or blob
storage). Whenever possible, the image repo should be able to deposit an
image using the block/blob API (e.g. EBS or S3 respectively for EC2) but
also maintain awareness of the name (e.g. AMI ID) that would be used for
the same image in the instance-creation API.
For EC2, once bundling is done you need to call 'RegisterImage' to
create the ami from the S3 Object, and then this ami shows up in your
list of images. Similarly for Rackspace once you make a snapshot the new
image becomes available and shows up in the response of a 'GET /Images'.
Does image repo need to keep the ami or just the S3/Cloudfiles location?
In the case where an image
is a completely separate type of object we'd have to stub out the data
object but hopefully can still attach all of the tags/metadata that the
repo uses to keep track of images.
what kind of info do you need to attach? I know rackspace allows you to
attach metadata to an object - not too familiar with the specifics of
that but can find out more if we need this to be part of the deltacloud
API cloud store collection.
=====================================================
Q. Which of our currently supported clouds offers a generic 'upload
data/blob/object to our storage service and access from anywhere even
from machines outside our cloud' - type storage?
=====================================================
--i--> Amazon Web Services (AWS) offers the Simple Storage Service (S3)
[1] - not to be confused with S4 [2]
We might also need to account for EBS-based AMIs, especially because of
the S3 size limitation (sizes are unlimited in tabled BTW).
yes of course EBS is another matter to look at in due course - we
currently have some support for EBS volumes (and snapshots). By size do
you mean the 5GB Object limit or something else?
--ii-> Rackspace allows you to snapshot a running Instance [5]
** This is done through a REST API call (POST /images) where you
specify the serverid (Instance) that is to be saved.
** Here there is no seperation between 'make snapshot' and 'upload
to cloud storage' - i.e. cannot export a server image [8].
** Snapshots stay 'attached to the server' [9] (i.e. saved locally?).
** Once process complete the image is available for booting a server
[5].
** 'Custom Image Upload' is in the Cloud Server API Roadmap [5].
Once you've POSTed an image, is that image retrievable using CloudFiles,
or are images totally stranded in a separate namespace from other objects?
thats right they are stranded somewhere (you dont even get an indication
of where exactly) - weirdly they don't expose the images via CloudFiles
and you cant directly upload them to there (if you want to access them
from the CloudServers service). You just do a snapshot and then the
image appears in your Images list. They don't currently charge for
snapshot and there are some imposed limits (they call it 'backup' - you
can even schedule this via their API which is kind of neat) but the plan
is to allow you to put these images into CloudFiles and then get charged
for space.
-iii-> Gogrid allows you to save a 'MyGSI - Gogrid Server Image' from
your own, preconfigured 'sandbox server'
** You create a MyGSI from a configured, running 'image sandbox
server' and the new image is added to Gogrid's cloud storage [11]
** Weirdly this cloud storage is not exposed at all via the API
** The API call is grid.image.save [12] - you create a new 'image
sandbox server' using 'grid.server.add', configure it and run the 'prep
scripts' and then call the save. Once complete the new MyGSI is
available in your list of images.
I've also found this process less than reliable. To be more precise,
every time I tried it just sat there for half an hour or so and then
threw up.
yeah - i never actually tried this I was just going on what the API
says. Again the situation here is similar to Rackspace - Gogrid have a
cloud storage service, they use that for images - but do not expose
those images to you (in fact, they do not expose their cloud storage
service at all for that matter).
marios
