Show Tech's Design and Code Intent¶
Show Tech in action¶
Show Tech was written to capture errors and include them in the output instead of failing or stalling. I don't know the name of this design methodology, but it is very useful when you want as much data in a single go as possible and do not want the poor soul running the code to have to troubleshoot stack traces and other errors. As a diagnostic tool Show Tech does it's best to run each check as designed and return the output. Please use this as a design choice and keep that methodology.
Show_tech_checks¶
Checks will be written as a combination python code to perform the check and yaml formatted data to run the check. The check.yaml file will be written to account for argument passing. The entry_point.py file will be written in a way that a dictionary can be passed by importing the check.yaml file with parameters around how the check.py file will be run. This will allow run_check.py to pass a check dictionary to entry_point.py and not care about the details. Object oriented programming (OOP) is neat.
To aid in additions to the app and more checks, each check will be a standardized file. Checks will have properties for enabling or disabling by default. This will allow us to roll checks out slowly or toggle off certain ones by a Nautobot admin. The intent is that checks could be enabled or disabled from the Nautobot GUI, this is not a feature at this time. Checks will have properties and parameters. Some of these may be immutable. Parameters will help structure the arguments a user could pass into Show Tech to run the check.
First Set of Checks¶
- utilize the subprocess module for running commands against a host
- entry point will be a wrapper for the subprocess module
- will focus on human readable responses from the check. An option for json data output will always be included.
- will allow output to be put into a zip file.
Second and Beyond Set of Checks to be added later¶
- Should follow the same guidelines for development as the first set of checks.
- Each check should have a check.yaml file which has an enyry point into a check.py file
Scripts in Show Tech¶
run_check.py was designed to handle the running of checks as if they were actions.
helpers.py was designed for common tasks which will be relied upon by Show Tech but are generic functionality.
update_readme.py was designed to update the readme in the show_tech_checks folder and keep check information up to date.
Show Tech Input¶
Show Tech can be run a few ways. The primary way is via finding all enabled: true
key:value in each rachet_check.yaml file. Then outputting via Zip file of all checks ran with the results being stored as yaml files. This provides an immediate answer without customizing any outputs. This behavior can be overridden.
1) Enabled checks - search for all show_tech_checks/*.yaml files and find all checks with
enabled: true
2) Single
3) Idea: Multiple - Still thinking on this one. Not available currently
Show Tech Output¶
Show Tech can output in 3 consistent ways currently. The primary way is via API and a json payload will be generated in the same structure as the yaml example below. This behavior can be overridden.
1) via api
2) via a temp directory where the data will be wiped on reload and a zip file output
3) via output to the screen
Examples¶
# yaml example provides key descriptions
# json example provides an actual output for API consumption
check_name:
command: check_name command being ran
command_result: capture and return result of running command
command_result_status: enum options of `Success`, `Failure`, `Error`
command_result_type: best estimate for string, json, or raw text in `command_result`
command_result_error: capture and return any errors when running the command through the entry_point.
entry_point_error: capture and return any errors when running the entry_point script
output_version: versioning output for better API handling
{
"check_name": {
"command": "date",
"command_result": "Mon Oct 9 02:04:26 UTC 2023",
"command_result_status": "success",
"command_result_type": "best estimate for string, json, or raw text in `command_result`",
"command_result_error": "None",
"entry_point_error": "None",
},
"output_version": "v1"
}