Best way to format complex findings for end-user consumption?
12 views
Skip to first unread message
Johnnie Green
Aug 24, 2021, 6:55:25 PM8/24/21
to Ansible Development
Hi,
Is there a clean and efficient 'ansible' way by which the playbook developer can gain more control over the formatting of information to be put in front of the resource that executes the playbook?
I'm relatively new at developing with ansible, having developed only about a half dozen playbooks that execute in a dev-ops like environment, where the goal of my playbooks has been to validate configuration and ensure requested customizations/configuration changes can be made safely and consistently.
In some cases, the playbook encounters configuration drift or other findings where it seems unwise to resolve the finding in an automated manner and instead seems better to abort while highlighting the need for manual review/remediation.
When the Play aborts it has a lot of detailed information about the problem that needs to be communicated back to the resource who initiated the Playbook as the focus of the manual review needed. To date I have been struggling to format this in a suitable way for the resources to easily relate to, which is surprising --- surely this level of reporting is a fundamental tenet for computer automation?
I'm not looking for anything too sophisticated, just a way to output some static text (ideally controlling indentation, line and paragraph boundaries) and also merge in some output from previously executed commands or dynamically created 'dict' / 'list' objects, such that escaped newlines are expanded and reasonably complex findings from the execution can be consumed in a way that is easy to follow.
While researching this topic I've seen similar questions raised in different forms over many years but never really seen these adequately addressed. I'm therefore aware of custom (and less efficient) ad-hoc approaches that have been suggested and also about 'ANSIBLE_STDOUT_CALLBACK', but don't want to change formatting as globally (I don't control the config and am not the only developer implementing playbooks) or even on the command line.
In general I am happy enough with the formatting of task related output and the formatting achieved for general calls to 'debug' (like how it formats a 'dict' when using the 'var:' directive). The requirement here seems just a corner case where having more control would be beneficial to clearly set out a specific finding that is the basis for the Playbook aborting and therefore needs to be easily understood so the operator is clear on what needs to be reviewed further.
To accommodate this flexibility it seems surprising that the built in 'debug' module doesn't have a number of modifiers so the developer can utilize additional formatting when the need arises, perhaps something like:
debug:
expand_newlines: true
format_mask: "{{ Service: %s (pid: %d)\nConfig:\n%j\n",
service_name, service_pid, json_config }}"
In absence of any support for formatting more natively, in modules like 'debug', is there any way to control formatting when writing to a file (perhaps building it over multiple tasks) and then getting ansible to just cat the file to stdout at the very end, so that the output retains formatting and doesn't get missed in with other formatting (perhaps via a handler?).
Any ideas welcomed --- I've experimented a lot and researched a lot but am surprised not to have achieved the limited additional formatting needed to ensure findings can be presented in a way that is easily relatable.
Sorry for the long posting and thanks in advance for any input you might be able to offer.
Is there a clean and efficient 'ansible' way by which the playbook developer can gain more control over the formatting of information to be put in front of the resource that executes the playbook?
I'm relatively new at developing with ansible, having developed only about a half dozen playbooks that execute in a dev-ops like environment, where the goal of my playbooks has been to validate configuration and ensure requested customizations/configuration changes can be made safely and consistently.
In some cases, the playbook encounters configuration drift or other findings where it seems unwise to resolve the finding in an automated manner and instead seems better to abort while highlighting the need for manual review/remediation.
When the Play aborts it has a lot of detailed information about the problem that needs to be communicated back to the resource who initiated the Playbook as the focus of the manual review needed. To date I have been struggling to format this in a suitable way for the resources to easily relate to, which is surprising --- surely this level of reporting is a fundamental tenet for computer automation?
I'm not looking for anything too sophisticated, just a way to output some static text (ideally controlling indentation, line and paragraph boundaries) and also merge in some output from previously executed commands or dynamically created 'dict' / 'list' objects, such that escaped newlines are expanded and reasonably complex findings from the execution can be consumed in a way that is easy to follow.
While researching this topic I've seen similar questions raised in different forms over many years but never really seen these adequately addressed. I'm therefore aware of custom (and less efficient) ad-hoc approaches that have been suggested and also about 'ANSIBLE_STDOUT_CALLBACK', but don't want to change formatting as globally (I don't control the config and am not the only developer implementing playbooks) or even on the command line.
In general I am happy enough with the formatting of task related output and the formatting achieved for general calls to 'debug' (like how it formats a 'dict' when using the 'var:' directive). The requirement here seems just a corner case where having more control would be beneficial to clearly set out a specific finding that is the basis for the Playbook aborting and therefore needs to be easily understood so the operator is clear on what needs to be reviewed further.
To accommodate this flexibility it seems surprising that the built in 'debug' module doesn't have a number of modifiers so the developer can utilize additional formatting when the need arises, perhaps something like:
debug:
expand_newlines: true
format_mask: "{{ Service: %s (pid: %d)\nConfig:\n%j\n",
service_name, service_pid, json_config }}"
In absence of any support for formatting more natively, in modules like 'debug', is there any way to control formatting when writing to a file (perhaps building it over multiple tasks) and then getting ansible to just cat the file to stdout at the very end, so that the output retains formatting and doesn't get missed in with other formatting (perhaps via a handler?).
Any ideas welcomed --- I've experimented a lot and researched a lot but am surprised not to have achieved the limited additional formatting needed to ensure findings can be presented in a way that is easily relatable.
Sorry for the long posting and thanks in advance for any input you might be able to offer.
Johnnie Green
Aug 25, 2021, 10:12:02 AM8/25/21
to Ansible Development
Not sure if markdown will work as I hope in the post (will post images if not) but thought a brief illustration may prove helpful on the default formatting achieved via a task using the 'debug' module (and how difficult it is to relate to) in comparison to if the desired limited formatting were easily possible:
Default (no effort made in the Playbook to control formatting but I have attempted to break lines in the post to simulate how it would be presented on a typical terminal):
Limited formatting (I have left the line break symbols in for easier visualization where the line breaks occurred against the above):
Surely allowing the developer a little more control over the formatting of certain messages is possible/worthwhile?
Default (no effort made in the Playbook to control formatting but I have attempted to break lines in the post to simulate how it would be presented on a typical terminal):
><pre>TASK [Display Warning When Any Service Is Found Not Running Where Expected After the Relocate Operation]************************
ok: [core1] => {
"msg": "(UNEXPECTED-STATUS)\nThe following represents the status of micro services following the 'relocate'
operation:\n{'microservice-a': {'previous_host': 'node04', 'previous_ip': '192.0.2.4', 'target_host': 'node05',
'target_ip': '192.0.2.5', 'actual_ip': '192.0.2.5'}, 'microservice-b': {'previous_host': 'node04', 'previous_ip':
'192.0.2.4', 'target_host': 'node05', 'target_ip': '192.0.2.5', 'actual_ip': '192.0.2.4'}, 'microservice-c':
{'previous_host': 'node04', 'previous_ip': '192.0.2.4', 'target_host': 'node05', 'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.5'}, 'microservice-d': {'previous_host': 'node04', 'previous_ip': '192.0.2.4', 'target_host':
'node05', 'target_ip': '192.0.2.5', 'actual_ip': '192.0.2.4'}}\nThe following micro services are not running where
expected:\n{'microservice-b': {'previous_host': 'node04', 'previous_ip': '192.0.2.4', 'target_host': 'node05',
'target_ip': '192.0.2.5', 'actual_ip': '192.0.2.4'}, 'microservice-d': {'previous_host': 'node04', 'previous_ip':
'192.0.2.4', 'target_host': 'node05', 'target_ip': '192.0.2.5', 'actual_ip': '192.0.2.4'}}\nPlease take manual
action to stop the following services at their current location and start them at their intended location."
}</pre>
Limited formatting (I have left the line break symbols in for easier visualization where the line breaks occurred against the above):
> <pre>TASK [Display Warning When Any Service Is Found Not Running Where Expected After the Relocate Operation] ************************
ok: [core1] => {
"msg": "
(UNEXPECTED-STATUS)\n
The following represents the status of micro services following the 'relocate' operation:\n
{
'microservice-a': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.5'
},
'microservice-b': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.4'
},
'microservice-c': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.5'
},
'microservice-d': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.4'
}
}\n
The following micro services are not running where expected:\n
{
'microservice-b': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.4'
},
'microservice-d': {
'previous_host': 'node04',
'previous_ip': '192.0.2.4',
'target_host': 'node05',
'target_ip': '192.0.2.5',
'actual_ip': '192.0.2.4'
}
}\n
Please take manual action to stop the following services at their current location and start them at their intended location."
}</pre>
Surely allowing the developer a little more control over the formatting of certain messages is possible/worthwhile?
Richard Megginson
Aug 25, 2021, 8:26:40 PM8/25/21
to Johnnie Green, Ansible Development
Have you tried the `to_nice_json` filter? https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#formatting-data-yaml-and-json
--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/fa271bfd-f282-4817-b9b0-438c08410802n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages