Using Software Factory to manage Red Hat OpenStack Platform lifecycle

by Nicolas Hicher, Senior Software Engineer – Continuous Integration and Delivery

Software-Factory

Software-Factory is a collection of services that provides a powerful platform to build software. It enables the same workflow used to develop OpenStack: using Gerrit for code reviews, Zuul/Nodepool/Jenkins as a CI system, and Storyboard for stories and issues tracker. Also, it ensures a reproducible test environment with ephemeral Jenkins slaves.

In this video, Nicolas Hicher will demonstrate how to use Software-Factory to manage a Red Hat OpenStack Platform 9 lifecycle. We will do a deployment and an update on a virtual environment (within an OpenStack tenant).

Python-tripleo-helper

For this demo, we will do a deployment within an OpenStack tenant. Using a tool, developed by the engineering team that builds DCI, called python-tripleo-helper. With this tool, we can do a deployment within an OpenStack tenant using the same steps of a full deployment (boot server via IPMI, discover nodes, introspection and deployment). We also patched python-tripleo-helper to add an update command to update the OpenStack (changing parameters, not doing a major upgrade).

Workflow

The workflow is simple and robust:

  • Submit a review with the templates, the installation script and the tests scripts. A CI job validates the templates.
  • When the review is approved, the gate jobs are executed (installation or update).
  • After the deployment/update is completed, the review is merged.

Deployment

For this demo, we will do a simple deployment (1 controller and 1 compute nodes) with Red Hat OpenStack 9.0

Limitations

Since we do the deployment in a virtual environment, we can’t test some advanced features, especially for networking and storage. But other features of the deployed cloud can be validated using the appropriate environments.

Improvements

We plan to continue to improve this workflow to be able to:

  • Do a major upgrade from Red Hat OpenStack Platform (X to X+1).
  • Manage a bare metal deployment.
  • Improve the Ceph deployment to be able to use more than one object storage device (OSD).
  • Use smoke jobs like tempest to validate the deployment before merging the review.

Also, it should be possible to manage pre-production and production environments within a single git repository, the check job will do the tasks on pre production and after receiving a peer’s validation, the same actions will be applied on production.

Who is Testing Your Cloud?

Co-Authored with Dan Sheppard, Product Manager, Rackspace

 

With test driven development, continuous integration/continuous deployment and devops practices now the norm, most organizations understand the importance of testing their applications.

But what about the cloud those applications are going to live on? Too many companies miss this critical step, leading to gaps in their operations, which can lead to production issues, API outages, inability to upgrade, problems when trying to upgrade and general instability of the cloud.

It all begs the question: “Do you even test?”

At Rackspace, our industry leading support teams use a proactive approach to operations, and that begins with detailed and comprehensive testing, so that not only your applications but your cloud is ready for your production workload.

Critical Collaboration

For Rackspace Private Cloud Powered by Red Hat, we collaborate closely with Red Hat; we test the upstream OpenStack code as well as the open sourced projects we leverage for our deployment, such as Ceph and Red Hat OpenStack Platform Director. This is done in a variety of ways, like sharing test cases upstream with the community via Tempest, creating and tracking bugs, and creating bug fixes upstream.

Continue reading “Who is Testing Your Cloud?”