Distributions [LWN.net]

News and Editorials

Fedora launches Cloud SIG

January 27, 2010

This article was contributed by Nathan Willis

The Fedora project started an interest group focused on cloud computing recently. Red Hat's Greg DeKoenigsberg kicked off the effort by launching a mailing list and inviting those interested in improving Fedora's support for cloud services to join. The first goal DeKoenigsberg proposed is to create modern, well-maintained Fedora images for Amazon's Elastic Compute Cloud (EC2) service — but there are many other potential goals on the horizon.

First things first: EC2

According to DeKoenigsberg's initial email to the list, the impetus for the new group is that the most recent Amazon Machine Images (AMIs) Amazon provides for EC2 are based on Fedora 8. Released in late 2007, Fedora 8 shipped with kernel 2.6.23, and naturally includes now outdated versions of important libraries and tools. Moreover, when users try to update their Fedora 8 AMIs, the updates appear to fail, thus giving Fedora a black eye from the user's perspective.

In fact, it is not possible to update an AMI to a new kernel as one would with a physical machine; the AMI itself is a read-only Xen virtual machine image that is restored to its saved state on each new instance, including a reboot. In addition to that, the AMI does not itself contain a kernel image; rather it is linked to a separate Amazon Kernel Image (AKI) via an XML manifest file. Consequently, users can try to update the kernel in their AMIs, but when rebooted, the virtual machines load the AKI kernel linked to in the manifest rather than the kernel that appeared to be installed via the package updater. EC2 users can build their own AMIs (with recent kernels and packages) and share them with the public, but the publicly available Fedora images are reportedly of buggy quality — and a potential security risk.

EC2's design is not Fedora's fault, of course, but as DeKoenigsberg put it, the confusion among end users is an opportunity for the distribution to step in and help build better tools. On the mailing list, Fedora project members have subsequently begun hashing out plans to create the updated AKI and AMI images based on current, Fedora 12 sources. The group is also hoping to work with Amazon on a way to brand its Fedora AMIs as the "official" images, to distinguish them in the minds of EC2 customers from home-brewed images that might not work reliably.

Following AMI testing, the group plans to add creating the EC2 image to the existing Fedora release process.

What next?

Updated AKIs and AMIs are relatively straightforward, so list discussion naturally turned to what other projects the group should undertake. Among the ideas are providing a tool set for users to easily customize their own AMIs based on the official Fedora images (similar to the way Fedora "spins" are created), providing a Fedora mirror running within EC2 to provide packages to other EC2 users. Cloud services outside of EC2 (such as Eucalyptus and Rackspace) are important too, but the decision to focus initially on EC2 is based on the Amazon service's popularity.

In addition to building images for other cloud platforms, one of the group's stated goals is to build tools and APIs to enable Fedora users to migrate their instances from one cloud service to another — including in-house "private clouds" of particular interest to corporate users.

This would potentially tie in to several existing Red Hat projects, such as oVirt, RHEV-M, and Deltacloud. oVirt and RHEV-M are virtualization management tools that would be useful for users running Fedora as their hypervisor OS. Deltacloud is an abstraction layer for applications running on cloud services; it attempts to provide APIs that allow the application to be moved from one cloud service to another without modification. It currently supports a REST API and Ruby bindings, with more reportedly on the horizon.

As DeKoenigsberg put it, Fedora can appear in the cloud computing stack in three places: as the hypervisor running the guest machines, as the management platform for the entire cloud, and as the guest operating system. Building reliable, modern EC2 images helps Fedora fulfill the third role, and affects the greatest number of current users, so it should be the first target. The hypervisor tools help Fedora fulfill the first role, so they also fall inside the scope of the cloud interest group. How to improve Fedora's suitability for middle role, however, remains an open question.

As long as we're here, what is a cloud anyway?

Perhaps predictably, the members of the new interest group have also engaged in the never-ending discussion over what defines "cloud computing" itself. In particular, is cloud computing different in any substantial way from virtualization, or is it merely a business model using virtualization technology?

The question is not an entirely academic one; to some, as a not-for-profit community project, Fedora should not focus its energies on building business tools for Red Hat, particularly the presently closed-source RHEV-M. Red Hat is pursuing a cloud computing strategy; it held a forum in July 2009 and has just announced a second for February 10, 2010. DeKoenigsberg expressed his opinion on the question, observing that although many cloud service vendors start by creating a "product," it is always built upon tools — but that if one starts by building good open source tools, a product of benefit to a company like Red Hat inevitably emerges. "I'm interested in tools approaches that help our users. I think that's the advantage that Fedora can provide — a group of knowledgeable folks who share and refine the best tools."

Essentially the process is the same as what has already happened in the server market. If the tools (such as Linux) are good enough, the opportunity to run a profitable business supporting them arises. Regardless of whether the most popular platforms are built upon entirely free software stacks, it is undeniable that users want to run Linux on cloud services. Fedora is wise to make sure that its distribution runs well on EC2 and other cloud services, and to lay the groundwork for serving well in whatever roles become popular in cloud computing, on Red Hat products or otherwise.