Red Hat Enterprise Linux OpenStack Platform – First Look

August 20, 2013

Cloud, Data Grid

I haven’t published that many posts this month. So, I present Two for Tuesday.

  • Red Hat Enterprise Linux OpenStack Platform – First Look
  • The JBoss Cloud Project (link)

First things first, Red Hat Enterprise Linux OpenStack Platform or Red Hat OpenStack / RHOS. I’ll refer to it as simply OpenStack. As mentioned in my last post, I’m going to spend August and September highlighting Java EE and JBoss EAP in the cloud. In my last post, I described the internal architecture of OpenShift by Red Hat. In particular, multitenancy and networking. This post is simply my first look at OpenStack (Grizzly).

Whereas OpenShift by Red Hat is a public (OpenShift Online) / private (OpenShift Enterprise) platform as a service (PaaS), OpenStack is public / private infrastructure as a service (IaaS).

I started with the Getting Started Guide (link), and it begins with the architecture / services / components.


Well, cloud infrastructure provides a whole lot more than multitenancy.

  • Dashboard (horizon)
    A web-based dashboard for managing RHOS services.
  • Identity (keystone)
    A centralized identity service that provides authentication and authorization for other services, and manages users, tenants, and roles.
  • OpenStack Networking (quantum)
    A networking service that provides connectivity between the interfaces of other RHOS services.
  • Block Storage (cinder)
    A service that manages persistent block storage volumes for virtual machines.
  • Compute (nova)
    A service that launches and schedules networks of machines running on nodes.
  • Image (glance)
    A registry service for virtual machine images.
  • Object Storage (swift)
    A service providing object storage which allows users to store and retrieve files (arbitrary data).
  • Metering (ceilometer)
    A service providing measurements of cloud resources.
  • Orchestration (heat)
    A service providing a template-based orchestration engine, which supports the automatic creation of resource stacks.

First Thoughts

Metering, while in technical preview, is an appealing service. I can see the value for an IT department in being able to measure the resource usage of individual departments. I’m building an internal cloud for JBoss products, and I’m considering the possibility of using the metering service to bill my colleagues. Eric and Kenny, that would be you.

Then there is block / object storage and orchestration engine. Now I’m thinking about JBoss Data Grid (JDG).

JDG supports multiple cache stores for persistence. I can’t help but wonder if it should include cache stores for block storage (cinder) and / or object storage (swift) services. On the other hand, what if JDG implemented the swift API?

While JDG is elastic, it does not scale (horizontally) automatically. I can’t help but wonder if the orchestration service (heat) could be used to automatically provision new nodes based on resource usage. For example, to provision a new node if the heap space is less than 50% free on any of the running nodes.

I’m Impressed

The documentation not only describes the purpose of each service, it lists the individual components of each service. For example, the dashboard service (horizon) is composed of a python web application (Django), an Apache HTTP Server, and a database.

You can’t judge a book by its cover, but you can judge software by its architecture.

I find the OpenStack architecture to be impressive. It is composed services. The services are composed of components including an API. The services may or may not rely on other services. For example, the compute service (nova) relies on image service (glance) and image service (glance) relies on the object storage service (swift).

What’s Next?

I read the documentation on manual installation and configuration (link). I’m planning to avoid this approach like a plague.

Thankfully, there is PackStack and Foreman (technology preview) and they both rely on Puppet. Installation with PackStack is covered in the getting started guide. Installation with Foreman is covered in the deployment guide (link).

PackStack can be run automatic mode for single node (controller + compute) or multi-node (controller + multiple compute) installation, interactive mode, or non-interactive mode with a configuration file. In addition to installing and configuring the OpenStack services, PackStack will install and configured required software (e.g. MySQL / Apache Qpid). I’m interested in the interactive or non-interactive modes as the controller services and required software do not have to be installed on the same node! It’s all about the architecture, and like I said, I find the OpenStack architecture to be impressive.

The only services that PackStack does not appear to install and configure are the metering service (ceilometer) and the orchestration service (heat). I did not see anything in the getting started guide regarding the installation and configuration of these services.

Then there is Foreman. I’ve read good things about Foreman, but it does not appear to be as flexible as PackStack. There are only two host groups available: controller node and compute node. In addition, Foreman installs and configures Nova Networking as it does not support OpenStack networking service (quantum). Further, the host group definitions do not include the block storage service (cinder). That being said, Foreman can provision bare metal servers via, for example, PXE.

Managing OpenStack with The Foreman (link)


About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: