libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Polvi <po...@cloudkick.com>
Subject Re: [libcloud] Re: Integrating Images for Providers and End Users
Date Mon, 03 May 2010 17:24:51 GMT
Hello,

Last night Paul and I took a stab at creating a spec for the image rendering
service. The actual manifest that defines the image is very cloudlets
inspired, but needs some tweaking to support the distributed nature of the
system.

http://wiki.apache.org/incubator/LibcloudImages

<http://wiki.apache.org/incubator/LibcloudImages>The goal is to actually
start hacking on an implementation of the service. From there, we would
write provider specific plugins (ala libcloud proper). The only catch is
that the plugin would exist on the providers infrastructure... and would
require the provider to officially support this.

What do you think? Which parts are confusing?

-Alex

On Tue, Apr 6, 2010 at 5:01 PM, Solomon Hykes <solomon.hykes@gmail.com>wrote:

> Paul,
>
> On Mon, Apr 5, 2010 at 8:04 PM, Paul Querna <paul@querna.org> wrote:
>
> > Fundamentally, I believe most providers do not want a complicated
> > system tied to booting nodes -- I believe any design needs to enable
> > them to already leverage their existing methods of distributing
> > images [...]
> > I believe the best way of integration for a provider, would be to add
> > a create image call to their API, which took a manifest file as the
> > payload.
> > [...] There is some discussion about the details of what
> > is included in the create_image call [...]
>
> That is a very sensible approach.
>
> >   The Provider would then return to the user an ID for this
> > image.  Inside the manifest file, it would reference a URL to a
> > tarball which contained the filesystem.  (There is some discussion
> > about the details of what is included in the create_image call, do you
> > PUT the whole tarball, reference it, encrypt it, sign it, etc, but IMO
> > these are details to be worked out, not a fundamental change in
> > architecture.)
>
> Agreed. The important things to remember are:
>
> 1- The user can create a provider-specific image from a custom cloudlet
>
> 2- The user experience for booting images remains exactly the same as today
>
> 3- We still have to figure out the best delivery mechanism. Whatever that
> turns out to be, the cloudlets format will evolve to accommodate it.
>
> 4. We are super-interested in getting feedback from hosting providers.
>
> > The key piece of software that would need to be constructed, is a
> > Cloudlets Rendering service. [...]
>
> >
> > Sebastien and Solomon are discussing how to implement a demo of the
> > Cloudlets Rendering Service, built on top of Amazon EC2. [...]
>
> >  I think as long as we made it in easily
> >
> > replaceable modules, I think we can make it work for everyone.
>
> Let us know if there's anything you'd like to see in the demo, beyond EC2.
> A favorite image format, distro, storage mechanism? We're all ears.
>
>
> PS we don't have cloudlets.com unfortunately. Check out
> http://gocloudlet.org. It's better than nothing :)
>
> Best,
>
> --
> Solomon Hykes
> @solomonstre
> dotcloud.com
>



-- 
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message