all things open

In Part 1 of the Hands on with ManageIQ EVM series I walked through how easy it is to deploy and begin using EVM Suite. In part2, I’d like to explore how a workflow between EVM Suite and CloudForms can be established. This is important, because while some of the capabilities of EVM Suite and CloudForms overlap, there are vast areas where they compliment one another and together they provide a range of capabilities that is very compelling, and in many ways unmatched by any other vendors.

The Capabilities

EVM Suites’s capabilities fall squarely into providing operational management around infrastructure and virtual machines. CloudForms provides the ability to install operating systems into virtual machine containers and manage the content that is available or installed into the operating systems once the virtual machines are running. Of course, CloudForms also provides a self-service catalog which end users could interact with to deploy application blueprints. This is an area of overlap and will likely be worked out over the roadmap of the products. In this workflow, we’ll attempt to use ManageIQ as the self-service portal, but it could just as easily have been CloudForms acting as the self-service portal.

The Chicken and Egg

One of the values that needs to be maintained during the workflow is the ability for CloudForms to manage the launched instances in order to be able to provide updated content (RPM packages) to them. The problem is that the images must be built using CloudForms Cloud Engine and they are being launched by a user via EVM suite. What is needed is a way to tell the launched instance to register to CloudForms System Engine. When CloudForms Cloud Engine is used to launch the instances it could execute a service on the launched instances to have them register to CloudForms System Engine. With EVM suite launching the instances I wasn’t aware of any way in which this could be passed into the virtual machines on launch. This might be a limitation of my knowledge of EVM suite. I’ll explore this further in the future.

Catwalk

To get around the chicken and egg problem I’ve created something I call Catwalk. It is a RPM package which once installed allows a user to specify a CloudForms System Engine for the instance to register to upon boot. You can download it here.

The logic works like this:

1. On installation catwalk places a line in /etc/rc.local to execute /opt/catwalk/cfse-register.

2. cfse-register defaults to looking for a host named catwalk and attempts to download http://catwalk/pub/environment.

3. if the file “environment” exists at http://catwalk/pub/environment it is used to set the variables for catwalk.

4. if the file “environment” does not exist then a default set of variables are used by catwalk from the catwalk.conf file.

5. the catwalk cfse-register script runs subscription-manager to register the system to the system engine.

In the future it would be more elegant if catwalk registered the instance to a puppet master and utilized it to register to system engine and apply/enforce configurations. For the time being, catwalk can be slip streamed into images during the step in which CloudForms builds provider specific images. This helps us get beyond the chicken and egg problem of system registration for ongoing updates of content.

The Proposed Workflow

The diagram below illustrates the workflow I was attempting to create between CloudForms and ManageIQ EVM.

Example Workflow

1. Synchronize the content for building a Red Hat Enterprise Linux virtual machine and the catwalk package into CloudForms System Engine or alternatively perform step 1a.

1a. CloudForms Cloud Engine is used to build the images. The targetcontent.xml file is edited to ensure that the catwalk package is automatically included in the images built.

<template_includes>
  <include target='rhevm' os='RHEL-6' version='3' arch='x86_64'>
    <packages>
      <package name='rhev-agent'/>
      <package name='katello-agent'/>
      <package name='aeolus-audrey-agent'/>
      <package name='catwalk'/>
    </packages>
    <repositories>
      <repository name='cf-tools'>
      <url>https://rhc-cfse2.lab.eng.bos.redhat.com/pulp/repos/Finance_Organization/Administrative/content/dist/rhel/server/6/6.3/x86_64/cf-tools/1/os/</url>
      <persisted>No</persisted>
      <clientcert>-----BEGIN CERTIFICATE-----
my unique certificate here
-----END CERTIFICATE-----
</clientcert>
      <clientkey>-----BEGIN RSA PRIVATE KEY-----
my unique key here
-----END RSA PRIVATE KEY-----
</clientkey>
      </repository>
      <repository name='catwalk'>
      <url>http://rhc-02.lab.eng.bos.redhat.com/pub/repo/catwalk/</url>
      <persisted>No</persisted>
      </repository>
    </repositories>
  </include>
</template_includes>

2. CloudForms Cloud Engine pushes the images to Red Hat Enterprise Virtualization.

3. EVM Suite discovers the templates.

4. When a user launches a virtual machine based on the template, the catwalk package executes and registers the virtual machine to CloudForms System Engine.

5. CloudForms System Engine can manage the virtual machine as it runs.

The Problem

As I went to implement this workflow I ran into a problem. Today, EVM Suite requires a gPXE server for RHEV in order to launch virtual machines. It does not support strictly launching a virtual machine from a template. I will be working with the team to determine the best way to move forward in both the short and long term to move beyond this.

Short Term Possibilities

In the short term I’m going to try to slip stream the catwalk RPM into the gPXE environment. This will hopefully allow an OS to be built via EVM and have it attach to CloudForms System Engine automatically. This effectively removes CloudForms Cloud Engine from the workflow. I’ll provide an update once I get to this point.

Future Suggestions

There are a LOT of suggestions I have floating around in my head, but here are just a few changes that would make this workflow easier and more valuable in the future.

First, include the image building capabilities within the providers of Red Hat Enterprise Virtualization, vSphere, and OpenStack. If the imagefactory was viewed as a service within the provider that EVM was aware of and could orchestrate there would be no need to include CloudForms Cloud Engine in the workflow. This would eliminate an extra piece of infrastructure required and simplify the user experience while maintaining the value of image building. The virtualization/cloud provider has the physical resources required to build images at scale anyway, so why perform it locally on a single system when you have the whole “cloud” at your disposal?

It would also be useful to build a custom action into EVM Suite that automatically deletes the registered system in CloudForms System Engine once the virtual machine is removed in EVM suite. This would automate the end of the lifecycle.

One area of further thought is creating a workflow for provisioning that is easy and flexible. For example, maintaining the image building capabilities but also allowing for installation via gPXE (or a MaaS) and being able to reconcile the differences between that and an existing image would be ideal.