The introduction of Embedded Ansible with CloudForms 4.5 enabled administrators to create CloudForms services that use Ansible playbooks instead of Ruby methods to perform tasks. Successive versions of CloudForms have expanded this capability, and automation developers can now construct complex CloudForms Automate workflows using Ansible playbooks alongside traditional Ruby methods.
Part 1 of this series will discuss two Ansible roles that have been included in CFME 5.9.2 and later. The roles enable an embedded Ansible playbook to integrate closely with CloudForms and participate in an automation workflow. They are:
manageiq-core.manageiq-automate – this role provides a simple way of accessing Automate workspace objects. It is usable from playbook methods only.
manageiq-core.manageiq-vmdb – this role provides a simple way of manipulating VMDB objects that are exposed via the API. It is usable from both playbook methods and playbook services.
Usage of both roles is demonstrated throughout the remainder of this series of articles.
The manageiq-automate Role
The manageiq-core.manageiq-automate role can be used by playbook methods (but not services) to interact with CloudForms automation. This allows a playbook method to participate in an automation workflow and share data with other objects in the workflow’s workspace.
The following is an example of how the role can be used:
vars:
– manageiq_validate_certs: false
roles:
– manageiq-core.manageiq-automate
tasks:
– name: Get the “rhel_subscription_pool” attribute from a configuration domain instance
manageiq_automate:
workspace: “{{ workspace }}”
get_attribute:
object: “/Configuration/OpenShift/Parameters”
attribute: “rhel_subscription_pool”
register: get_attribute_result
The role uses a manageiq_validate_certs internal variable to determine whether to validate the SSL connection back to the API. The default for this value is true, but must be overridden to false if the default CloudForms self-signed SSL certificate is used. This can be done using a playbook var or input parameter (i.e. extra_var) called manageiq_validate_certs with the boolean value of false, for example:
Functions
The manageiq-automate module contains many functions that can be broadly divided into four categories, as follows.
Working with Input Parameters
A playbook method’s input parameters can be queried and retrieved using the following functions:
method_parameter_exists
get_method_parameters
get_method_parameter
get_decrypted_method_parameter
Working with Workspace Objects
Workspace objects (instances that are already loaded in the $evm workspace) can be queried using the following functions:
object_exists
get_object_names
get_object_attribute_names
get_vmdb_object
Working with Object Attributes
Workspace object attributes can be queried, retrieved and set using the following functions:
attribute_exists
get_attribute
get_decrypted_attribute
set_attribute
set_attributes
set_encrypted_attribute
Working with State Machines
A state machine’s state variables can be retrieved or set using the following functions when a playbook method is running in the state machine:
get_state_var_names
state_var_exists
get_state_var
set_state_var
set_retry
Return Values
The get_* and *_exists functions return their values into a variable using the register command, for example:
– name: Get the “rhel_subscription_pool” attribute from a configuration domain
manageiq_automate:
workspace: “{{ workspace }}”
get_attribute:
object: “/Configuration/OpenShift/Parameters”
attribute: “rhel_subscription_pool”
register: get_attribute_result
– debug: msg=”Result:{{ get_attribute_result }}”
The return value from these commands is typically a hash, and the value of interest has the value key in this hash. For example the debug line above will print the following:
ok: [localhost] => {
“msg”: “Result:{‘changed': False, ‘value': ‘Red Hat OpenShift Container Platform, Premium*’, ‘failed': False}”
}
If the variable is to be used elsewhere in the playbook it should therefore be referenced using the value key, for example {{ get_attribute_result.value }}.
Some of the functions return an object, for example get_decrypted_attribute returns a hash whose value key itself points to a further object hash, for example:
– name: Get the “ldap_user_password” encrypted attribute from a configuration domain
manageiq_automate:
workspace: “{{ workspace }}”
get_decrypted_attribute:
object: “/Configuration/OpenShift/Parameters”
attribute: “ldap_user_password”
register: get_decrypted_attribute_result
– debug: msg=”Result:{{ get_decrypted_attribute_result }}”
ok: [localhost] => {
“msg”: “Result:{‘changed': False, ‘value': {‘object': ‘/Configuration/OpenShift/Parameters’, ‘attribute': ‘ldap_user_password’, ‘value': ‘so_secret’}, ‘failed': False}”
}
If the variable is to be used elsewhere in the playbook it should be referenced with the value.value key, for example {{ get_decrypted_attribute_result.value.value }}.
The manageiq-vmdb Role
VMDB objects that are accessible via the RESTful API can be accessed using functions defined in the manageiq-core.manageiq-vmdb role, documented here. The role is usable from both playbook services and playbook methods.
Like the manageiq-automate role, this role also uses a manageiq_validate_certs internal variable to determine whether to validate the SSL connection back to the API. The default for this value is true, and this must be overridden to false if the default CloudForms self-signed SSL certificate is used.
The following is an example of how the role can be used:
vars:
– manageiq_validate_certs: false
roles:
– manageiq-core.manageiq-vmdb
tasks:
– name: Get the service object
manageiq_vmdb:
href: “{{ manageiq.service }}”
register: service
– name: Get the VM object
manageiq_vmdb:
href: “vms/18″
register: vm
– name: Rename the service
manageiq_vmdb:
vmdb: “{{ service }}”
action: edit
data:
name: “New Engineering VM”
description: “VM created on {{ lookup(‘pipe’, ‘date +%Y-%m-%d %H:%M’) }}”
– name: Add the VM to the service
manageiq_vmdb:
vmdb: “{{ service }}”
action: add_resource
data:
resource:
href: “{{ vm.href }}”
The actions available to an object are those described in the API reference guide.
CFME Appliance Hostname
If no appliance hostname has been set from appliance_console, the embedded Ansible provider may fail to connect back to itself when running these roles. As error such as the following may be logged:
MIQ(ManageIQ::Providers::EmbeddedAnsible::Provider#authentication_check_no_validation) type: [“default”] for [2] [Embedded Ansible] Validation failed: error, Failed to open TCP connection to https:443 (getaddrinfo: Name or service not known)
To prevent this error, always ensure that the appliance hostname has been defined.
Summary
This article has described two very useful Ansible roles that are supplied out-of-the-box with CloudForms. The following articles in this series illustrate further how the roles can be used by a playbook that is run as part of a CloudForms automation workflow.
Quelle: CloudForms
Published by