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: