Mailing-List: contact deltacloud-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltacloud-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jdarcy@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4C3F044D.7040406@redhat.com>
Date: Thu, 15 Jul 2010 08:51:25 -0400
From: Jeff Darcy <jdarcy@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: deltacloud-dev@incubator.apache.org
Subject: Re: Cloud Storage and Image upload - Instance snapshot via deltacloud
 core API
References: <4C3B420F.5050607@redhat.com> <4C3E61C4.8080703@redhat.com>
 <4C3EF554.7050304@redhat.com>
In-Reply-To: <4C3EF554.7050304@redhat.com>
Content-Type: multipart/alternative;
 boundary="------------020801090203070101030002"

--------------020801090203070101030002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/15/2010 07:47 AM, marios@redhat.com wrote:
> > 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'

The "tabled" component of Hail exactly implements the original S3 API 
extensions, including Amazon-style authentication and so on.  I think 
the only significant gap is partial-object GET, which is being worked on 
practically as we speak.  It also doesn't do some of the CDN extensions, 
or later additions such as versions, but otherwise it's just the same as 
Amazon's own S3.  I regularly test repod against both, with no code 
differences at all.

>  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?

If the AMI name and the S3 name are the same, that's great.  I think I'd 
be a little more comfortable if we kept the store/fetch name and the 
image-instantiation name separate in our model, though, just in case 
they're different in some future cloud.

>  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.

The facility repod provides is very similar to CloudFiles, or for that 
matter S3 - arbitrary key/value pairs representing anything the user 
wants.  If they care about release status or security levels, for 
example, they can just go and define their own tags for those; repod 
itself just treats them all as opaque.  However, though the basic 
functionality is similar, tags at the repod level are stored in a 
database so they can be (a) queried efficiently and (b) used in 
replication policies.  Neither S3 nor CF provides this functionality, 
and they also have number/size limits that might be insufficient.

>
> > 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?

I mean the 5GB per-object limit.  We might well need to consider EBS 
sooner rather than later because, while it might be more than enough for 
most purposes, for VM images specifically 5GB might seem a bit tight.

> > 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.

Ugh.  Maybe we can encourage them (and GoGrid) to do better.


--------------020801090203070101030002--