Jump to: navigation, search


  • Created: Tue, 20 Dec 2011 13:40:15 -0800
  • Contributors: Joshua Harlow

RHEL parity


We propose a blueprint to help Open Stack be supported in RHEL 6 (and other RHEL based system, i.e. Fedora and Centos) in a manner comparable to the support and testing (from all perspectives, developers and users), it provides to Ubuntu environments.


Openstack users would like to be able to develop and run on various linux distributions, with RHEL (and derivatives) being one of primary distributions that many companies and people use. We would like to use RHEL 6 as a hypervisor (with KVM) and add development effort to make sure that RHEL 6 can be a supported development platform as well as used as the main openstack control fabric for all the openstack components. As for a virtual machine client we want to ensure that RHEL 4.5 - 6 can be used in virtual machines and configured correctly (networking...) with the correct settings & functionality to be equivalent (or as close as possible) to a ubuntu client.



From a high level this would involve the following:

  1. Update the templating of libvirt.xml and ensure that its values will work for RHEL as well as ubuntu guests. This is guest operating system dependent as certain guest operating systems (ie RHEL 5.6) do not support virtio disk input, but can support ide based disk input (among other issues with the current libvirt template).
  2. Possible modify cloud-init for rhel usage?

Expected Code Changes

Diablo branch (may change in essex):

nova/virt/libvirt/firewall.py (as needed)
nova/virt/libvirt/linux_net.py (as needed)
... (might encounter others)
... (new files for abstraction layer and implementations) 

Expected Documentation Changes

We should provide documentation on how to setup a RHEL system and guests as a subsite (it would be nice to have one for each distro that openstack is being used on). This site should provide install scripts/programs… similar to devstack.org (maybe even the same site?) that will work with different operating systems and different releases. This site would need to be updated for each stable release as well as explaining what the dependencies are for development and development milestone releases, ideally either providing the necessary packages (rpm) or explaining how to get those (from yum).


The following packages would need to be built and made available via a RHEL repo (may change for essex release):

Note: this list is what grid-dynamics has come up with, since there does not seem to be a listing of exactly what versions/packages are needed for each release.

erlang >= R14B
euca2ools >= 1.3.1
python-amqplib >= 0.6.1
python-anyjson >= 0.3.1
python-boto >= 1.9b
python-carrot >= 0.10.7
python-daemon >= 1.5.5
python-eventlet >= 0.9.15
python-gflags >= 1.4
python-greenlet >= 0.3.1
python-httplib2 >= 0.4.0
python-json >= 3.4
python-kombu >= 1.1.3
python-lockfile >= 0.8
python-mox >= 0.5.3
python-nose >= 1.0.0
python-routes >= 1.12.3
python-sqlalchemy-migrate >= 0.7.1
python-webob >= 1.0.8
python-wsgiproxy >= 0.2.2
pyxattr >= 0.6.1
rabbitmq-server >= 2.1.1
(+dependencies of above)
(others as needed…)

Test/Demo Plan

In order to test this we will need to be able to run the current unit tests on ubuntu and on RHEL (and any other operating systems) and ensure that everything is working according to those unit tests. If those unit tests do not exist or are themselves operating system specific we will need to create new unit tests that do not have this restriction and we will have to replace the previous unit tests.

As for integration tests we will need to ensure that the openstack hudson/jenkins (https://jenkins.openstack.org/) instance creates RHEL integration tests (with guests from RHEL 4.5 -> RHEL 6) and tests those to ensure functionality is working as expected as well as testing those same functionality points on other operating systems (ubuntu…). If those integration tests/E2E do not exist, we will have to make them. We will also need to make sure that LXC and UML and XenServer are not affected by the code changes and dependencies added (or deleted). We will have to depend on unit tests, integration tests and any existing E2E tests to ensure that this is correct, and will be for future code changes that others make.

Migration Plan

Previously existing code should work with this new set of abstraction code. Since there is no existing RHEL approved implementation there is no need for a migration plan for that distro. It is the goal that all unit tests should work as expected since the ubuntu mechanism should still continue to function (qemu-nbd, loopback...).

Unresolved Issues

  1. Who will build/maintain these packages that are not in the base RHEL 6 repository (see above)?
  2. Will we not depend on libguestfs and just make this "parity" use "raw" images since there is no qemu-nbd in rhel6?