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 <[email protected]> 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: > 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. 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 @solomonstre dotcloud.com
