Nobody likes being lied to. If two credible sources tell you different answers to the same question life gets hard. Imagine the poor computer that trusts what anyone tells it. If it asks for a piece of info it accepts the answer and makes changes based on it. If that source is an outdated copy of the data set or wasn’t copied quite right in the first place then the automation engine doesn’t stand a chance.
Let’s run with an example. You have a list of routers and their IP addresses. It is copied on Thursday from the place the team maintains into a form that Ansible can use (maybe added manually to a host file). On Monday an important config change is needed to all 130 of them. The smart engineer uses automation to make the change and everyone is impressed with the speed the network is bought back to a fully operational state.
Clever automation engineer.
However, those two routers installed on Friday, which are a long drive away, and were added to the main database by the team as normal, we’re unknown to Ansible. So in reality only 130 of 132 devices were updated.
At this point the problem might be known by a fault that is obvious to all (and embarrassing to the automation engineer) or another process might be checking for the critical update. More likely everyone assumes the automation engine did its thing correctly and troubleshooting begins.
Either way two things have gone wrong here:
- An unnecessary fault/risk condition
- The manual process to export data from the source
At this point a common fix is to put a process in place so that the information the automation tool holds is updated I concert with the other source. So when router 133 is installed the task list includes requires the installer to update Ansible as well as the asset database.
Problem solved. Ansible is kept up to date and all changes pushed out globally.
The situation is far from ideal as the setup fails to understand the point of automation. It’s purpose in life is to reduce human interaction to save time and reduce the risk of error. At some point a human will make a mistake. Problems will occur.
In the ideal scenario the automation engine (and every other type of tool available to the engineer) knows only of the Single Source of Truth (SSoT). An automatic task gets the required info from the source. Ony one database is ever edited meaning the minimal amount of human interaction. More over this might allow that single source to be the most human usable tool, e.g. a GUI front ended database.
This concept works both ways. Sometimes the automation engineer is the first to know a fact. This doesn’t make it the source of truth. Just the temporary holder of that fact. If the installation of the routers in this example was initiated by Ansible then it might in some setups be the first to know about a name or IP address. In the SSoT model it would automatically update the central database rather than remember it in a VAR file.
So a good test of an automation setup might be that it holds no information in its files. It only ever knows how to get that information from the SSoT.
Constantpinger 