incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Solomon Hykes <>
Subject Re: [libcloud] All about Images
Date Tue, 30 Mar 2010 07:28:26 GMT

Thanks for starting the conversation!

Building libcloud.images on top of Cloudlets sounds great. We'll be
happy to help.

As for Cloudlets joining the libcloud/asf umbrella, it seems to make a
lot of sense. Combining image management and allocation in a single
cli tool would be killer. The format specs would have to exist
independently, though, so that other libraries can implement it.

I suggest we sit down at the next cloudhackers meetup and draft a
roadmap for this.

On Monday, March 29, 2010, Paul Querna <> wrote:
> Where to start.
> Images today are one of the other major stumbling blocks for most
> users of clouds -- not just building, but the versioning and
> distribution of the images are still too painful.  People revert back
> to using traditional configuration management tools, because
> re-rolling a server image is a time consuming and painful procedure.
> In addition, there is no abstraction layer between generating the most
> common image format, Amazon's AMI, and other formats, preventing wider
> adoption and support of image formats by other hosting providers.
> I have talked about it on IRC in #libcloud, and in person with a few
> people, about maybe expanding the scope of the libcloud project, to
> include "Cloud Images".
> I think if libcloud took the same approach to images that it took to
> APIs -- start simple, support everyone, get the hosting providers
> involved, and iterate quickly, we could get good adoption of an image
> format and specification quite quickly, where other complicated
> standards have faltered.   In addition, because libcloud is about
> producing actual software, not just a specification, I feel like we
> could provide the tools to providers to make integration of the image
> format extremely simple.
> I think the most interesting project in this space right now is
> dotCloud's cloudlet:
> The short version is they use a filesystem, integrated with version
> control, and that is able to export to various formats, from a chroot,
> to a tarball, or an AMI.  There is also support for templating things
> like configuration files inside the image, which will make it very
> easy to support multiple cloud providers with a single baseline image.
> I think the most interesting possibility is to build on Cloudlet
> (maybe even convince cloudlet's authors to join us inside the ASF),
> but I am getting ahead of myself there :-)
> What does everyone else think about Cloud Images?  Does it belong in a
> place like libcloud, or do you feel that the standardization efforts
> elsewhere are sufficient?
> Thanks,
> Paul

Solomon Hykes

View raw message