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.

Install your OpenStack Cloud before lunchtime

Figure 1. The inner workings of QuickStart Cloud Installer

What if I told you that you can have your OpenStack Cloud environment setup before you have to stop for lunch?

Would you be surprised?

Could you do that today?

In most cases I am betting your answer would be not possible, not even on your best day. Not to worry, a solution is here and it’s called the QuickStart Cloud Installer (QCI).

Let’s take a look at the background of where this Cloud tool came from, how it evolved and where it is headed.

 

Born from need

As products like Red Hat Cloud Suite emerge onto the technology scene, it exemplifies the need for companies to be able to support infrastructure and application development use cases such as the following:

Continue reading “Install your OpenStack Cloud before lunchtime”

TripleO (Director) Components in Detail

In our previous post we introduced Red Hat OpenStack Platform Director. We showed how at the heart of Director is TripleO, short for “OpenStack on OpenStack”. TripleO is an OpenStack project that aims to utilise OpenStack itself as the foundations for deploying OpenStack. To clarify, TripleO advocates the use of native OpenStack components, and their respective API’s to configure, deploy, and manage OpenStack environments itself.

The major benefit of utilising these existing API’s with Director is that they’re well documented, they go through extensive integration testing upstream, and are the most mature components in OpenStack. For those that are already familiar with the way that OpenStack works, it’s a lot easier to understand how TripleO (and therefore, Director) works. Feature enhancements, security patches, and bug fixes are therefore automatically inherited into Director, without us having to play catch up with the community.

With TripleO, we refer to two clouds: The first to consider is the undercloud, this is the command and control cloud in which a smaller OpenStack environment exists that’s sole purpose is to bootstrap a larger production cloud. This is known as the overcloud, where tenants and their respective workloads reside. Director sometimes is treated as a synonymous to the undercloud; Director bootstraps the undercloud OpenStack deployment and provides the necessary tooling to deploy an overcloud.

undercloud vs overcloud

Continue reading “TripleO (Director) Components in Detail”

Introduction to Red Hat OpenStack Platform Director

Those familiar with OpenStack already know that deployment has historically been a bit challenging. That’s mainly because deployment includes a lot more than just getting the software installed – it’s about architecting your platform to use existing infrastructure as well as planning for future scalability and flexibility. OpenStack is designed to be a massively scalable platform, with distributed components on a shared message bus and database backend. For most deployments, this distributed architecture consists of Controller nodes for cluster management, resource orchestration, and networking services, Compute nodes where the virtual machines (the workloads) are executed, and Storage nodes where persistent storage is managed. general

The Red Hat recommended architecture for fully operational OpenStack clouds include predefined and configurable roles that are robust, resilient, ready to scale, and capable of integrating with a wide variety of existing 3rd party technologies. We do this with by leveraging the logic embedded in Red Hat OpenStack Platform Director (based on the upstream TripleO project).

With Director, you’ll use OpenStack language to create a truly Software Defined Data Center. You’ll use Ironic drivers for your initial bootstrapping of servers, and Neutron networking to define management IPs and provisioning networks. You will use Heat to document the setup of your server room, and Nova to monitor the status of your control nodes. Because Director comes with pre-defined scenarios optimized from our 20 years of Linux know-how and best practices, you will also learn how OpenStack is configured out of the box for scalability, performance, and resilience.

Why do kids in primary school learn multiplication tables when we all have calculators? Why should you learn how to use OpenStack in order to install OpenStack? Mastering these pieces is a good thing for your IT department and your own career, because they provide a solid foundation for your organization’s path to a Software Defined Data Center. Eventually, you’ll have all your Data Center configuration in text files stored on a Git repository or on a USB drive that you can easily replicate within another data center.

In a series of coming blog posts, we’ll explain how Director has been built to accommodate the business requirements and the challenges of deploying OpenStack and its long-term management. If you are really impatient, remember that we publish all of our documentation in the Red Hat OpenStack Platform documentation portal (link to version 8).

Continue reading “Introduction to Red Hat OpenStack Platform Director”

Integrating classic IT with cloud-native

This is the fifth and final in a series of posts that delves deeper into the questions that IDC’s Mary Johnston Turner and Gary Chen considered in a recent IDC Analyst Connection. The fifth question asked:

What types of technologies are available to facilitate the integration of multiple generations of infrastructure and applications as hybrid cloud-native and conventional architectures evolve?

Mary and Gary write that “We expect that as these next-generation environments evolve, conventional and cloud-native infrastructure and development platforms will extend support for each other. As an example, OpenStack was built as a next-generation cloud-native solution, but it is now adding support for some enterprise features.”

This is the one aspect of integration. Today, it’s useful to draw a distinction between conventional and cloud-native infrastructures in part because they often use different technologies and those technologies are changing at different rates. However, as projects/products that are important for many enterprise cloud-native deployments–such as OpenStack–mature, they’re starting to adopt features associated with enterprise virtualization and enterprise management.

Continue reading “Integrating classic IT with cloud-native”

OpenStack 2015 – The Year of the Enterprise?

OpenStackSummit Paris 2014This post is the collective work of all the Red Hat Enterprise Linux OpenStack Platform Product Managers who attended the summit.

The 11th Openstack design summit that took place last week for the first time in Europe, brought about 6000 participants of the OpenStack community to Paris to kick off the design for the “Kilo” release.

If 2014 was the year of the “Superuser”, then clearly the year 2015 seems to be about the “Year of the Enterprise“.  The big question is: are we ready for enterprise mass adoption?

More than year ago, at the Openstack Havana design summit, it was clear that although interest in deploying OpenStack was growing, most enterprises were still holding back, mainly due to the lack of maturity of the project. This OpenStack summit, the new cool kid in the Open Cloud infrastructure playground is finally starting to show real maturity signs.

An important indicator for this is the increased number of deployments. The Kilo summit showcased about 16 different large organizations using production workloads on OpenStack, including companies such as BBVA Bank, SAP SE (formerly SAP AG) & BMW.

Continue reading “OpenStack 2015 – The Year of the Enterprise?”

OpenStack Resources for the vAdmin

Across many enterprise organizations, IT is driving innovation that allows companies to be more agile and gain a competitive edge. These are exciting times for the Vadmins who are at the center of this change. This innovation starts with bridging the gap between traditional virtualization workloads and cloud-enabled workloads based on OpenStack.

Organizations are embracing OpenStack because it allows them to more rapidly scale to meet evolving user demands without sacrificing performance on a stable and flexible platform and at a cost effective level.

As a Vadmin, you might be asking yourself how OpenStack fits in your world of traditional virtualization workloads. The answer is that OpenStack is not a replacement rather it is an extension to traditional virtualization platforms.

To help vAdmins get started with OpenStack, we have created a dedicated page with numerous OpenStack resources including a solutions guide that explains the architectural differences between OpenStack and VMware vSphere, as well as an appliance that allows you to quickly run and deploy OpenStack in your VMware vSphere environment.

Visit this OpenStack Resources vAdmin page to learn how to get started with OpenStack in your existing infrastructure today.

Is this really OpenStack? Infrastructure Modeling, Easy Deployment & Cloud Operator Dashboards…Yes!

OpenStack is on the verge of greatness

For fellow Stackers, this statement is obviously opinionated. But for those new to or in the early stages of exploring OpenStack, let us give you an objective view, a teaser if you will as to why we feel this statement is true.

Some interesting developments are taking place in the community. These developments are focused on the ability to deploy and manage OpenStack. The quick summary here is that as these developments mature — they will provide the leverage needed to accelerate the adoption of OpenStack by orders of magnitude.

Continue Reading