On 07/15/2010 07:47 AM, [email protected] 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.
