CloudForms blog is moving to ManageIQ

In the next few weeks, and with the goal of better aligning this content with the upstream ManageIQ, we will migrate all relevant content to the upstream blog before shutting down this blog platform.

You’ll be able to find all your favorite tips and tricks at

CloudForms with Infoblox using Ansible Part 1: Prerequisites

In this blog series, we will cover how to integrate Infoblox IPAM with  Red Hat CloudForms using Ansible Playbooks. Before we start, let me point you that we already have a detailed blog on  CloudForms with Infoblox integration written by John Hardy[1] which has explained how to integrate CloudForms with Infoblox using Ruby scripts. 

Now the question is if we already have a detailed blog on this then what new I would bring to this blog? 

Continue reading “CloudForms with Infoblox using Ansible Part 1: Prerequisites”

Which button should I click on?

Which button should I click on?


As a CloudForms user, do you ever get frustrated, wondering which button to click on or how to get to your selected location?


If your answer to any of these or similar questions is yes, then let me tell you that your life is going to get easier. Why does CloudForms need to be that complicated? The truth is that it doesn’t and we (with your help) are working on it.

Continue reading “Which button should I click on?”

How to utilize Ansible Tower Jobs in Catalog Bundles

Red Hat CloudForms allows users to put both VM provisioning and Ansible Tower jobs in the same catalog bundle, with the intention of having that tower job of customizing the VM that was just provisioned.  However, it’s not as simple as adding a VM catalog item, and then an Ansible Tower catalog item. This post will guide you through the nuances of utilizing Tower jobs in CloudForms step by step.


Why can’t I just use Update on Launch when CloudForms is a source in Red Hat Tower’s inventory?


You can, as long as you don’t mind the jobs not being concurrent for that inventory.  If you have this option checked, then whatever concurrent jobs you have, will wait, since Tower does not update the inventory while a job is being executed.


However, if you wish to have concurrent jobs utilizing CloudForms, please continue reading this blog post.  This is the most efficient method utilizing CloudForms I’ve run across and we are currently using this in our lab environment for reproducers in North America for CloudForms CEE team.  A caveat of this is that you cannot have 2 VMs of the same name in your CloudForms environment, if you do, the limit will potentially be set to all of the VMs that match that name.


So how do I update the inventory for the newly provisioned host to Tower if we’re not updating on launch?


We will be utilizing an ansible playbook to use an API call to ad hoc add a host to the CloudForms inventory in Ansible Tower


What roles do I need to have enabled on the worker appliance for this to work?


  • Automate
  • Embedded Ansible
  • Provider Inventory
  • Provider Operations


You will also need to add the appropriate VM provider and Ansible Tower provider


Setting up the repository for embedded ansible


Go to Automation > Ansible > Repositories > Add New Repository, and use the following URL:


You will need to set the tower_user and tower_password extra vars on your own for this to work.  This user will need to have modification rights on the inventory you’re utilizing for the tower job.  You can do this through automate, service dialog, a vault/vars file or by modifying the playbook directly.


Customizing automate


You will need to create a new automate domain, for the example, my GitHub repository, it will be lab_maintenance.


  1. Copy and modify AutomationManagement/AnsibleTower/Operations/StateMachines/Job/wait_for_ip method


  • Original line:   ip_list = vm.ipaddresses
  • Changed line:  ip_list = vm.ipaddresses.grep(/\./)


The reason for this modification is to wait for an ipv4 address, as CloudForms by default just waits for the first IP it discovers and it’s usually an ipv6 address.


  1. Then create an ansible playbook method, picking the playbook found in the synced repository, with the following modifications:
  • Hosts is set to ${/#miq_provision.destination.ipaddresses.sort.first}
  • Input parameters are set as followed:

You will need to change the inventory number to whatever your inventory number is from tower that you want to utilize with the job template.  You can find the inventory number by navigating to the inventory in the Ansible Tower UI and inspecting the URL


  1. Create an instance called vm_name_limit and set it to the following:

Create a method in the same class and have it filled out like so:


vm_name = $evm.root[‘dialog_option_1_vm_name’]

unless vm_name.nil? ||

limit = $evm.object

limit[“data_type”] = “string”

limit[“required”] = “true”

limit[“value”] = vm_name



This sets the limit to the dialog_option_1_vm_name dialog field, which ansible tower uses as the host, if you’re using CloudForms as a source for the inventory


  1. Copy and modify the instance /Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/template


Add the WaitForIP and Playbook steps to the VMProvision_VM class after PostProvision and fill out the values like so:

Creating the Service Dialog


We will need to create a service dialog with 2 necessary fields:


  • option_1_vm_name
  • limit


The limit is dynamic, and the entry point is set to the vm_name_limit instance we created earlier.  This is so we can set the limit to the vm that was just provisioned. Create this field first.


Create the option_1_vm_name field second, as it’s static, and you’ll need to select “limit” under Fields to Refresh under the Options tab


Creating the Catalog bundle


Create a VM catalog item and then create an ansible tower job catalog item.  Then add both items to the bundle. Have the VM catalog item be 1st, and the tower job second.  In the following example, the CloudForms 4.7 catalog item is the VM catalog item, and Quick Setup is the ansible tower job item

Wrapping up


After all that you should be good to go!  These are the steps I’ve had to create since provisioning a CloudForms appliance and having the post provision modifications from Tower took around 30 minutes each.  If I had just done the update on launch option on the inventory, we would only be able to provision a reproducer every 30 minutes. Now with this, we can have concurrent jobs, enabling us to provision any number of reproducers in the same 30 minute time window.  I have examples of an automate domain and service dialog you can utilize in the same github repository as the one mentioned for the playbook, so you can skip all of this and import them as you wish.  

Using Ansible workflows in CloudForms

Ansible continues to grow and is the strategic automation engine for Red Hat’s business. Having a solid and constantly improving integration with Ansible is key for CloudForms’ future success.


Ansible Tower Workflows are widely used in by the industry to orchestrate and govern interactions between different playbooks. CloudForms has been able to run Ansible Tower Jobs since its 4.1 release. Starting with CloudForms 4.7, we will expand this support and will be able to utilize Workflows from the Service Catalog.

Continue reading “Using Ansible workflows in CloudForms”

Walkthrough : Customizing VM Post Provisioning Task

Red Hat Cloudforms provides several ways to customize virtual machine provisioning,  the out-of-the-box VM Provisioning State Machine has multiple steps through which VM provisioning request crawl, among them one of the step is PostProvison, this step is used to perform post-provisioning activities on the provisioned virtual system.  In this article, I will explain how to customize PostProvison method using an example of ‘add an additional disk to the VM’ use case.

Continue reading “Walkthrough : Customizing VM Post Provisioning Task”

Tips from the tour part 3: Automating complex processes with Ansible



Red Hat held an event on the infrastructure part of our portfolio in Milan and Rome on April 17th and 19th, 2018. Part of the demos presented was focused on the Automation topic managed with Red Hat Ansible and Red Hat Ansible Tower:


The event information and agenda is available at:


This is the third part of the series of articles written by my colleague Rinaldo Bergamini you can find them here and here.

In this part, I would like to show you how you can Automate “everything” with Red Hat Ansible and Ansible Tower.

Continue reading “Tips from the tour part 3: Automating complex processes with Ansible”

Playing with REST API


In this article, I will describe how REST API works natively in Red Hat CloudForms.

REST stands for Representational State Transfer. REST is a web standard based architecture and uses HTTP protocol for data communication. It revolves around resources where every component is a resource and is accessed by a common interface using HTTP standards method.  

Red Hat CloudForms provides APIs to integrate external systems and initiate provisioning via CloudForms. In CloudForms, REST can be accessed by adding “/api” prefix to the URL.  


https://<IP or hostname of appliance> /api/

Continue reading “Playing with REST API”