Red Hat OpenStack Technical Preview

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, Inc. as
one of its platinum members. OpenStack’s momentum extended beyond the
Foundation. The OpenStack Summit drew over 1,000 attendees. They’ve
seen advancements on the code base, now on its sixth (‘Folsom‘)
release. And they’ve seen 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.

The
process Red Hat follows to turn a community project, such as
OpenStack, into a product for our commercial customers is the
following: 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 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 innovation.

What’s
New in Folsom:

The
Folsom release represents continued advancements, thanks in part to
the growth of the OpenStack community. By OpenStack’s count, Folsom
saw a 65% 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, US, Inc. 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 VMs. For example, a new ‘host aggregation’ feature
places workloads into the resource pools for which they are suited.
One resource pool could be optimized for a particular processing
task, such as a set of servers optimized with graphics processing
units for HPC 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 an
extensible networking model. A plug-in mechanism lets different
technologies implement calls made through the Quantum API. This
enables organizations to recreate the network topologies found in
enterprise environments. While the 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 block storage project, though that functionality was previously
embedded in Nova. It joins OpenStack Object Storage (Swift), which
also gained enhancements in Folsom. Some of these are operational,
such as improved access to monitoring metrics, enabling Swift to take
advantage of 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.

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
  essential 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 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 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 offering, which gives
developers an 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.