It's been a big year for OpenStack.
Even back in January, it was already enjoying strong developer and user interest. The project, while still relatively young, was on its fourth (“Diablo”) release. Perhaps as importantly, although all the details were not yet in place, plans to form an OpenStack Foundation were announced early in 2012—key to creating a structure for decision-making and contributions, whether code, financial or otherwise.
The vision of that Foundation has since become a reality, with Red Hat as one of its platinum members. OpenStack’s momentum extended beyond the Foundation. The OpenStack Summit drew well over 1,000 attendees. They've seen continuing advancements on the code base, now on its sixth (“Folsom”) release. And they've seen steady advancement on the road to commercial product offerings based on OpenStack. In Red Hat's case, we're now making available a new OpenStack Technical Preview based on Folsom, an update to our prior Technical Preview based on the “Essex” release.
We've previously written about the process Red Hat follows to turn a community project, such as OpenStack, into a product for our commercial customers. In a nutshell, this means bringing the same systematic engineering and release processes to OpenStack that Red Hat has for products such as Red Hat Enterprise Linux, Red Hat Enterprise Virtualization, Red Hat CloudForms and JBoss Enterprise Middleware. Stability, robustness and certifications are key components of enterprise releases. The challenge—one that Red Hat has years of experience meeting—is to achieve the stability and robustness that enterprises need without sacrificing the speed of upstream innovation.
What's New in Folsom: The Big Picture
The Folsom release represents substantial and continued advancements, thanks in part to the continuing growth of the OpenStack community. By OpenStack's count, Folsom saw a 65 percent increase in contributors over its previous release. A post on Bitergia dives further into the contributor numbers. Their analysis shows that hundreds of individuals from 49 companies contributed code across Folsom's seven core projects. (This analysis shows that developers affiliated with Red Hat were the #2 contributor group overall; Rackspace is the top contributor group.) As a result of these developer contributions, the OpenStack Folsom release included 185 new features.
Much of the new code went into OpenStack Compute (a.k.a. “Nova”), improving ease of use and adding other optimizations, especially for larger pools of virtual machines. For example, a new "host aggregation" feature places workloads into the resource pools for which they are best suited. One resource pool could be optimized for a particular processing task, such as a set of servers optimized with graphics processing units (GPU) for high performance computing work, while others remain general purpose. This would also enable a user to treat a group of servers as an independent unit for regulatory compliance reasons. Folsom also adds the ability to do live migration (i.e., move running virtual machine instances from one physical server to another).
With Folsom, two new projects were added to the OpenStack platform: OpenStack Networking (Quantum) and OpenStack Block Storage (Cinder).
Quantum breaks out the networking component from Nova compute, enabling a more flexible and extensible networking model. A plug-in mechanism lets different technologies implement calls made through the Quantum API. This enables organizations to recreate the complex network topologies typically found in enterprise environments. While the overall industry trend we’re seeing is towards flatter networks, the reality is that private and hybrid clouds still need to recognize and handle the existing complexities that can't and won't disappear overnight. Quantum API extensions are also intended to provide additional control over security, compliance, quality-of-service and monitoring.
Cinder is a new block storage project, though that functionality was previously embedded in Nova. It joins OpenStack Object Storage (Swift), which also gained significant enhancements in Folsom. Some of these are operational, such as improved access to monitoring metrics, enabling Swift to take advantage of solid-state drives (SSDs) for storing metadata in situations where there's a need for high-write performance or simply a large number of objects. Other features add flexibility when dealing with hardware failures. The availability of these multiple storage services demonstrate the flexibility of the OpenStack framework, enabling users to create multiple services optimized for particular types of workloads and use cases.
How Red Hat Contributed to Folsom
Many of Red Hat's contributions to Folsom address enterprise customer requirements. These contributions fall into two primary areas: further improving the stability of the OpenStack community code and introducing new capabilities. As with Red Hat's work in the open source community, any improvements to the code have been contributed directly to the relevant upstream projects.
Red Hat's specific contributions to OpenStack Folsom included the following:
Deployment Tools. We want to enable support for different deployment tools, infrastructures and approaches. Whether Puppet, Foreman or something else that the customer has already created or adopted as their standard deployment tool, our approach is to provide integration points that make it easier for the customer to plug in the deployment tool of their choice.
Introduction of update processes appropriate for enterprise software deployments. We helped create stable branches of OpenStack that enable older versions (such as Essex) to continue to receive updates via patches backported from a later version (for instance, Folsom). These patches are mostly bug fixes and security patches. This capability is critical to creating an enterprise product, which requires a predictable lifecycle, and the ability to support the software in that environment.
Generalization of OpenStack. We continued to work on generalizing OpenStack to make it less closely tied to specific implementations of Linux or protocols. For example, we generalized OpenStack to the Advanced Message Queuing Protocol (AMQP). We also created meta-plugins in Quantum allowing the deployment of heterogeneous network architectures instead of being limited to a single network architecture or vendor. All of this provides both the project and customers greater flexibility and reduces dependencies that could cause instabilities or lock-in down the road.
Continuous integration tooling. In addition to our internal test and qualification processes, we have focused on upstream testing through a project called Smokestack. Smokestack looks at patches as they get committed to the upstream master branches and tests them. This provides very early feedback on whether or not any regressions (unintended side effects introduced by new code) result from that code being committed. This helps the upstream community project to become more stable by identifying issues earlier in the process.
Heat Project. We started the Heat project, which allows for multi-instance orchestration of guests. For example, you can create a deployment template for a workload that needs to deploy one instance each of a web, app and database server. The Heat template defines the dependencies and launches the trio as a complete functioning unit.
Foreman integration. We’ve worked on integrating Foreman, an open source provisioning tool, which does both bare metal and virtual guest provisioning.
Where OpenStack Fits at Red Hat
We expect OpenStack to play a big role in Red Hat cloud deployments to come.
OpenStack lets IT organizations stand up clouds that look and act like a cloud service provider. This Infrastructure-as-a-Service (IaaS) approach differs from and complements the virtualization management offered by Red Hat Enterprise Virtualization, which is more focused on enterprise use cases. Both OpenStack and Red Hat Enterprise Virtualization manage hypervisors and offer self-service—among other features—but they're doing so in service of different models of IT architecture and service provisioning.
Red Hat CloudForms then provides open, hybrid cloud management on top of heterogeneous infrastructure providers, whether an on-premise IaaS like OpenStack, public IaaS clouds like Amazon Web Services or Rackspace or virtualization platforms like Red Hat Enterprise Virtualization or VMware vSphere. CloudForms enables IT administrators to create application blueprints (for both single- and multi-tier/VM applications) that users can access from a self-service catalog and deploy across that hybrid cloud.
These infrastructure and management offerings are also complemented by OpenShift, Red Hat’s Platform-as-a-Service (PaaS) offering, which gives developers an easy on-ramp to developing in cloud environments. Unlike PaaS solutions that are limited to a specific provider, OpenShift can run on appropriately provisioned infrastructures, in both hosted and on-premise environments.
Making OpenStack Consumable
The story of cloud computing has been one of open source-fueled innovation—often directly driven by end users with a need. OpenStack is no exception. The broad community developing and supporting OpenStack includes end-user organizations that have demanding IT requirements. Red Hat is proud to play its own role in delivering innovation to the many open source communities with which we're involved, including OpenStack. We also have a vision to make that innovation consumable by our customers, which is why we're now offering a Technology Preview of OpenStack.
OpenStack doesn’t stand on its own – it now also has the backing of Red Hat as part of the larger Red Hat portfolio, which comes together to jointly deliver value to enterprise customers around the world.
It's been a big year for OpenStack.