This article documents the changes in Rackspace Private Cloud v4.2.0 and identified known issues.
For the release notes for previous versions, refer to the following articles:
Rackspace has developed a fast, free, and easy way to install a Rackspace Private Cloud powered by OpenStack in any data center. This method is suitable for anyone who wants to install a stable, tested, and supportable OpenStack-powered private cloud, and can be used for all scenarios from initial evaluations to production deployments.
Rackspace Private Cloud v4.2.
n supports the Havana release of OpenStack.
This document describes the updates in Rackspace Private Cloud v4.2.
n and any known issues in the product. You should already be familiar with Rackspace Private Cloud Software and have prior knowledge of OpenStack and cloud computing, basic Linux administration skills, and a side of bacon. :)
This version of the Rackspace Private Cloud Release Notes replaces and obsoletes all previous versions. The most recent changes are described in the table below:
|Revision Date||Summary of Changes|
|November 13, 2013||
For more information about sales and support, contact us at
>. For feedback on the product and the documentation, contact us at
>. For the documentation, you can also leave a comment at the Knowledge Center.
In addition to several stability and usability fixes, Rackspace Private Cloud v4.2.0 has the following changes.
The latest cookbook version number is
v4.2.0. This change is reflected in the instructions under Install the Rackspace Private Cloud Cookbooks.
NOTE: Rackspace Private Cloud v4.2.0 is based on the OpenStack Havana code base, and is being made available as an Early Access release to customers who want to deploy it in a proof-of-concept or other non-production environment. Rackspace Private Cloud v4.1.2, based on the OpenStack Grizzly code base, is recommended for production environments.
The following changes have been made to OpenStack support in Rackspace Private Cloud:
The Rackspace Private Cloud implementation of Metering is based on a MySQL framework and uses the SQL Alchemy. For more information about the parameters involved in this implementation, refer to the OpenStack documentation on Metering configuration options. For a list of database backends and what they support, refer to the OpenStack documentation on choosing a database backend for metering.
OpenStack Orchestration is not installed by default in the all-in-one or controller cookbooks, but can be installed afterward by applying the Heat roles to the Controller node.
The following changes have been made to High Availability in Rackspace Private Cloud:
The following changes have been made to OpenStack Networking in Rackspace Private Cloud:
neutron, reflecting the OpenStack project name change.
The following changes have been made to OpenStack Block Storage in Rackspace Private Cloud:
You can access Rackspace Private Cloud documentation on the Knowledge Center by clicking the Help link on the dashboard.
Rackspace has developed an Object Storage offering compatible with the Rackspace Private Cloud offering.
If you are interested in a deployment of Rackspace Private Cloud Object Storage, contact your Rackspace support representative for more information. You can work with Rackspace to have an Object Storage cluster configured in your data center or in a Rackspace data center. Contact Rackspace for more information.
OpenStack Object Storage is available as a General Access feature rather than an Early Access feature. For an overview of the Rackspace Private Cloud Object Storage architecture, refer to "Distributed Object Storage" on our Private Cloud Architectures page.
The following issues have been identified in Rackspace Private Cloud v4.2.0.
When a RabbitMQ cluster fails, it must be brought up in the reverse order in which it went down, or the restart will fail. For example, if RabbitMQ goes down on
controller1 and then on
controller2, the service should first be started on
controller2, and then on
Occasionally, failover between HA Controller nodes may fail due to multiple RabbitMQ processes existing on the secondary Controller node. Restarting RabbitMQ will bring the cluster back online:
#pkill -f rabbitmq; service rabbitmq-server restart
OpenStack Orchestration builds instance names based on the stack name, which results in long instance names. Instance names that are longer than 64 characters may cause the stack to fail to build. You should keep stack names short to avert this issue.
When using OpenStack Networking (Neutron), Controller nodes with Networking features and standalone Networking nodes require namespace kernel features that are not available in the default kernel shipped with CentOS 6.4, RHEL 6.4, and older versions of these operating systems. More information about Neutron limitations is available in the OpenStack documentation, and more information about RedHat-derivative kernel limitations is provided in the RDO FAQ.
Rackspace recommends that you upgrade to the latest RDO kernel if you are going to use CentOS or RHEL for networking nodes.
zero will cause snapshot deletion to fail in OpenStack Grizzly installations on CentOS. Rackspace recommends you set
none until this issue is resolved in OpenStack.
Rackspace Private Cloud is currently using the patch referenced in Ceilometer bug #1093625 to address issues with OpenStack Metering visualization. If the underlying packages are updated, you may experience patch issues. We will continue to monitor the status of this bug for future releases.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License