Adjusting formatting

posts/2023-09-21-graduating-automation/index.html

@@ -188,12 +188,16 @@ <h1>Graduating with Automation Practices</h1>
 <p>So where does this leave us? How does this help us answer the above questions and better define our initial approach?</p>
 <p>Red Hat has an internal automation community of practice. We publish our &ldquo;good practices&rdquo; publicly for everyone to read and benefit from. These practices get defined from our experience helping customers in the field, and these practices get updated and refined as we learn ourselves. One of the good practices regarding inventory and host management is around defining structured inventory: &ldquo;<a href="https://redhat-cop.github.io/automation-good-practices/#_define_your_inventory_as_structured_directory_instead_of_single_file">Define your inventory as structured directory instead of single file</a>&rdquo;. So this helps us define the ideal state, great! What about the approach to get here?</p>
 <p>In case you haven&rsquo;t guessed or noticed the theme here, the answer is it&rsquo;s going to be an iterative approach. There&rsquo;s two common techniques that can help you get started:</p>
-<p><strong>1. Inventory Exporting/Reporting w/ <a href="https://github.com/redhat-cop/controller_configuration/blob/devel/EXPORT_README.md">Red Hat Community of Practice controller_configuration Ansible collection</a></strong></p>
-<pre><code>This export tool can help you export your current AAP inventory into a text format like JSON where you can begin to parse it with whatever method you prefer to reconcile similar hosts, groups, types, functions, etc. and start to make some decisions around intelligent grouping of hosts. If you're familiar with data normalization, this is exactly the same process. Common grouping parameters are geographical location, technical function, business function, operating system derivatives (linux or windows, major version, etc.).
-</code></pre>
-<p><strong>2. Inventory Host Variable Reporting</strong></p>
-<pre><code>There's a variety of methods available to do this, I've written an [example playbook][3] that illustrates how this can be done. Using a report like this can help you group together common configuration artifacts like NTP server, DNS information, device services or purpose, etc. Using this information combined with the above helps you decide what commonality may exist across hosts. This can help you better define what should be handled in a host_var, group_var, role or default var, etc. Putting this in a text format helps you build a directory folder scaffolding structure for these common configuration artifacts and logic. A resource that can help in this area is the Ansible Variable Precedence order. Using this as a reference, you can decide where host variable classification should be, what might make sense as a sane default with other variable options that have an option to supersede it. For example:
-</code></pre>
+<ol>
+<li>
+<p><strong>Inventory Exporting/Reporting w/ <a href="https://github.com/redhat-cop/controller_configuration/blob/devel/EXPORT_README.md">Red Hat Community of Practice controller_configuration Ansible collection</a></strong></p>
+<p>This export tool can help you export your current AAP inventory into a text format like JSON where you can begin to parse it with whatever method you prefer to reconcile similar hosts, groups, types, functions, etc. and start to make some decisions around intelligent grouping of hosts. If you&rsquo;re familiar with data normalization, this is exactly the same process. Common grouping parameters are geographical location, technical function, business function, operating system derivatives (linux or windows, major version, etc.).</p>
+</li>
+<li>
+<p><strong>Inventory Host Variable Reporting</strong></p>
+<p>There&rsquo;s a variety of methods available to do this, I&rsquo;ve written an <a href="https://github.com/aludwar/ansible/blob/master/metrics/export_host_variables.yml">example playbook</a> that illustrates how this can be done. Using a report like this can help you group together common configuration artifacts like NTP server, DNS information, device services or purpose, etc. Using this information combined with the above helps you decide what commonality may exist across hosts. This can help you better define what should be handled in a host_var, group_var, role or default var, etc. Putting this in a text format helps you build a directory folder scaffolding structure for these common configuration artifacts and logic. A resource that can help in this area is the Ansible Variable Precedence order. Using this as a reference, you can decide where host variable classification should be, what might make sense as a sane default with other variable options that have an option to supersede it. For example:</p>
+</li>
+</ol>
 <p><img src="https://calgaryrhce.ca/wp-content/uploads/2023/09/ansiblevariableprecedence.png" alt="Ansible Variables Precedence"></p>
 <ul>
 <li>You may have NTP or DNS servers specific to a geographical region. These may make the most sense to include in the inventory group_vars. However, there may be some subregions like a DMZ that may have a different entry for this that is better placed in an inventory host_vars level.</li>