In this part of the lab, you will perform a series of tasks to customize the Provisioning State Machine of CloudForms. To better understand the following steps a quick introduction and overview of the process might be useful.
CloudForms provides two mechanisms for backend customization. Since CloudForms is written in Ruby we can use Ruby Methods for our changes. The awesome Mastering Automation in CloudForms and Mastering Automation in CloudForms Addendum are excellent sources to learn everything about these capabilities.
Since Red Hat acquired Ansible the integration with CloudForms is constantly improved. We can use Ansible Playbooks, Ansible Tower Jobs and Workflows in the Service Catalog, in the Automate State Machine and several other areas.
A State Machine describes a series of tasks which have to be executed. There are a number of State Machines as part of the product. For this lab, we will customize the Provisioning State Machine.
Starting with CloudForms 4.6 we can create Methods of type “Playbook” which, instead of running Ruby code, execute an Ansible Playbook. Staring in CloudForms 5.0, you can also use Ansible Tower Job Templates. Two different Tower Job Templates will be used in this lab.
Job Template - “VM info”: This Job Template will access the provisioning request object in the CloudForms Automate Workspace using the syncrou.manageiq-vmdb role to retrieve the VM name. After that it will build the fully qualified domain name of the host, which will be required by Satellite during the registration process. The part of the Job Template will use the syncrou.manageiq-automate role to create a state_var inside the Automate Workspace.
Job Template - “Satellite Registration”: Running this Playbook once the VM is provisioned, will register it with the Satellite Server. Remember that we tweaked the CheckProvisioned method in order to make sure that the VM is up and running before running this Playbooks.
Inside a CloudForms appliance the roles we’re using in this lab are already preinstalled, but named manageiq-core.manageiq-vmdb and manageiq-core.manageiq-automate. In CloudForms 5.0 the user is able to pass variables between Ansible and CloudForms Automate and vice versa. From CloudForms’ perspective any state_var can be accessed by a Playbook and from a Playbook you can use set_facts to store variables that can be access from CloudForms Automate. These capabilities can also be used to pass variables between different Ansible Playbooks and Ansible Tower Jobs.
If you want to know more about the new features and the roles, take a look at the CloudForms 5.0 Enablement presentation (you will need an Red Hat internal login to access this document).
A very common integration task is customize CloudForms to register new provisioned VMs in Satellite in the same provisioning State Machine.
In the lab environment an instance of Satellite is deployed and can be used. The following chapters will guide you through the process of implementing the necessary changes.
Prerequisites: If you have done other chapters of this lab before, it is necessary disable the previously created Automate Domain.
Create the VM Info Method: A new method based on an Ansible Tower Job Template will be created in order to interact with CloudForms.
Create the Satellite Registration Method: A new method based on an Ansible Tower Job Template will be created for registering VMs into Satellite as part of the provisioning state machine.
Edit the State Machine: After the new methods has been created is is needed to place them into new states inside states machine with the proper order.
Test the custom State Machine: The steps needed to test your custom state machine and make sure that the results are the expected ones.