Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of solomon.hykes@gmail.com
 designates 74.125.82.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=ZtyHim5QZZFR3yRd3wEpCJ22VVVK4EWcChEHt4ZjTZWPKTqoa3LXjLs2Qr7SFhionf
         ntinokqfFPreGm5R9lUDtQq90a0g/DWZLvuFaIedUUFbZddrUw5P46xDqg4FvLv6HWnk
         TlCwd2XPC3nQ+Ycq/yfYhKiIN8IvQTjqtFI+o=
MIME-Version: 1.0
In-Reply-To: <4239a4321003291804m76fb56enecfd1038bdacfad@mail.gmail.com>
References: <4239a4321003291804m76fb56enecfd1038bdacfad@mail.gmail.com>
Date: Tue, 30 Mar 2010 09:28:26 +0200
Message-ID: <febb9d781003300028x4ca7860ax339dfeaf746e83b5@mail.gmail.com>
From: Solomon Hykes <solomon.hykes@gmail.com>
To: libcloud@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [libcloud] All about Images

Paul,

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 <paul@querna.org> 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. =A0People 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. =A0 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:
> http://bitbucket.org/dotcloud/cloudlets/src/
>
> 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. =A0There 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? =A0Does it belong in a
> place like libcloud, or do you feel that the standardization efforts
> elsewhere are sufficient?
>
> Thanks,
>
> Paul
>

--=20
Solomon Hykes
@solomonstre
dotcloud.com