incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: Cloud Storage and Image upload - Instance snapshot via deltacloud core API
Date Thu, 15 Jul 2010 11:47:32 GMT
Hi Jeff, comments in-line:

On 15/07/10 02:17, Jeff Darcy wrote:
> On 01/-10/-28163 02:59 PM, marios@redhat.com 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

Mime
View raw message