<?xml version="1.0" encoding="UTF-8" standalone="yes"?><oembed><version><![CDATA[1.0]]></version><provider_name><![CDATA[CloudForms Now]]></provider_name><provider_url><![CDATA[http://cloudformsblog.redhat.com]]></provider_url><author_name><![CDATA[vestival]]></author_name><author_url><![CDATA[https://cloudformsblog.redhat.com/author/vestival/]]></author_url><title><![CDATA[Debugging Ansible Automation inside Red Hat&nbsp;CloudForms]]></title><type><![CDATA[link]]></type><html><![CDATA[<p><span style="font-weight:400;">Debugging might not be one of your favorite things to do, but when your automation fails it is good to know where to look to find information and troubleshoot. In this blog post, we investigate how to make sure Ansible Automation is correctly configured inside CloudForms, and how to troubleshoot issues that might occur when running Ansible Automation. Content for this blog post is based on the knowledge base article published on </span><a href="https://access.redhat.com/articles/3055471"><span style="font-weight:400;">Red Hat Customer Portal</span></a><span style="font-weight:400;">.</span></p>
<p>&nbsp;</p>
<p><!--more--></p>
<p>&nbsp;</p>
<h2><b>Before you start, make sure Ansible Automation is correctly configured and running</b></h2>
<p>&nbsp;</p>
<p><span style="font-weight:400;">First of all, before you start performing a deep debugging, make sure these steps are in place:</span></p>
<ul>
<li style="font-weight:400;"><span style="font-weight:400;">Embedded Ansible Role is enabled. Note that only one appliance per Region running Ansible Role is supported today.</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Internet connectivity is available for the appliance with the Embedded Ansible Role before the role is enabled. </span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Ansible Worker is properly running (you can check its status under Configuration &gt; Diagnostics).</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">You can restart the Embedded Ansible process by executing ansible-tower-service restart from the appliance command line.</span></li>
</ul>
<p>&nbsp;</p>
<p><span style="font-weight:400;">If the role is not properly configured and running, you will not be able to add playbooks or credentials. </span></p>
<p>&nbsp;</p>
<h2><b>Ok, Ansible Automation is up and running, but our playbook launches are not successful</b></h2>
<p>&nbsp;</p>
<p><span style="font-weight:400;">Well, in that case, you need to dig a bit more to figure out what is wrong:</span></p>
<ul>
<li style="font-weight:400;"><span style="font-weight:400;">Verify, under Services &gt; Request that the playbook is executed. Every playbook is executed as a service and status can be tracked here.</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">If the playbook does not execute as expected, check that the version of the playbook is appropriate and that you do not have further dependencies (like ansible roles or modules requirements). </span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Re-sync the repository from the CloudForms UI under Automation &gt; Ansible &gt; Repositories. On the appliance, playbooks can be found under /var/lib/awx/projects/.</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Check the standard output of the service to verify the execution of the playbook itself. This can be found under Services &gt; My Services &gt; Selected Services &gt; Provisioning &gt; Standard Output.</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Make sure all required playbook variables are provided to the playbook for execution. CloudForms can automatically create service dialogs while defining a new service to provide these variables. The dialog element name must match the playbook variable. </span></li>
<li style="font-weight:400;"><span style="font-weight:400;">The execution of the playbook in real time can be found in a file for each new run in the  /var/lib/awx/job_status directory. Note that the name of the file is a hash and has nothing to do with the playbook name. This is currently the only way to track the status of a run when executing the playbook as a policy or alert action.</span></li>
</ul>
<p>&nbsp;</p>
<h2><b>Where else can I find additional information?</b></h2>
<p>&nbsp;</p>
<p><span style="font-weight:400;">If all the above steps are validated and you still have trouble, a good place to continue troubleshooting is to look at the CloudForms standard log files under /var/www/miq/vmdb on the appliance: </span></p>
<ul>
<li style="font-weight:400;"><span style="font-weight:400;">Production.log &#8211; Operations UI &amp; Service UI</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Automation.log &#8211; Service Ordering, Automation</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Policy.log &#8211; Events, Policy</span></li>
<li style="font-weight:400;"><span style="font-weight:400;">Evm.log &#8211; Everything else</span></li>
</ul>
]]></html><thumbnail_url><![CDATA[https://cloudformsredhat.files.wordpress.com/2017/12/book-2617231_1920.jpg?w=1200&fit=440%2C330]]></thumbnail_url><thumbnail_width><![CDATA[440]]></thumbnail_width><thumbnail_height><![CDATA[293]]></thumbnail_height></oembed>