<p>This seems like the sort of thing that configuration management tools like ansible are intended to solve.  You can <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html#using-check-mode" rel="nofollow noreferrer">run ansible in check mode</a> to see what it would do.</p>

CC BY-SA 4.0
2021-03-20T09:24:52.263Z
Wow, I thought ansible was dead. It should be.
Software Engineer
CC BY-SA 4.0
2021-03-20T13:37:28.787Z
Ansible is one of the nicer configuration management systems available.  If puppet and chef are still kicking then ansible should be doing quite nicely for itself.
chicks
CC BY-SA 4.0
2021-03-20T14:21:05.353Z
I've not seen a single good argument for ansible since its inception. I believe it's broken by design, is solving the wrong problem, and is even doing that the wrong way.
Software Engineer
CC BY-SA 4.0
2021-02-16T21:13:26.337Z
2021-02-16T21:13:26.337Z
chicks
<p>I found <a href="https://pester.dev/" rel="nofollow noreferrer">Pester</a> which is just a powershell unit testing that can save Nunit XML results which can be published inside the pipeline.</p>
<p>It's not &quot;desired&quot;/&quot;current&quot; state I had hoped for but it can in the end provide a nice overview of all the &quot;things&quot; whose states I need to observe.</p>

CC BY-SA 4.0
2021-02-16T12:28:12.567Z
2021-02-16T12:28:12.567Z
Miroslav
<p>I've been trying to stick to the &quot;infrastructure as code&quot; principle as much as possible in my work.</p>
<p>But after the devops project got more complicated I started loosing the centralized perspective because the scope of used technologies and complexity are very rich: terraform, terraformer, terragrunt, pscore, bash, Azure CLI, Azure DevOps CLI, AzureAD module, msbuild, Java, various REST API calls...</p>
<p>So I started writting scripts and code that calculate &quot;desired vs current&quot; state just for validation and overview, if everything is in the right state. Most of the time this information is everything I need, I don't need to &quot;go to the desired state&quot; because sometimes that actually means manual intervention (sometimes even from someone else).</p>
<p>The output of these scripts is simple, currently they write into stdout something like this:</p>
<pre><code>Name of thing         Desired state      Current state     Result
----------------------------------------------------------------------
THING A               This               That              NOT GOOD
THING B               This               This              GOOD
THING C               This               ?                 Timeout after 5 minutes
...

Result: 
- 2 things needs attention
</code></pre>
<p>My question is if there is some tool or standard targeted at this specific use case?</p>
<ul>
<li>I have scripts, I could call them &quot;diff calculators&quot; that can output whether some &quot;thing&quot; or &quot;subthing of thing&quot; is in desired state and what is the current state</li>
<li>The tool produces nice table based UI output</li>
</ul>

CC BY-SA 4.0
2021-03-19T19:33:51.593Z
I wrote EXACTLY this tool, with EXACTLY the same columns, LOL, to check which microservices I need to deploy for a release.It's Gradle and ECS specific. I use ECS to get what versions are currently deployed (via AWS CLI commands), and use Gradle dependencies task to get what my desired versions are.
Chris F
<configuration-management>
Tool to produce nice output about desired vs. current state
Miroslav
# Tool to produce nice output about desired vs. current state

(Asked by: username_0 on 2021-02-14)

I've been trying to stick to the "infrastructure as code" principle as much as possible in my work.
But after the devops project got more complicated I started loosing the centralized perspective because the scope of used technologies and complexity are very rich: terraform, terraformer, terragrunt, pscore, bash, Azure CLI, Azure DevOps CLI, AzureAD module, msbuild, Java, various REST API calls...
So I started writting scripts and code that calculate "desired vs current" state just for validation and overview, if everything is in the right state. Most of the time this information is everything I need, I don't need to "go to the desired state" because sometimes that actually means manual intervention (sometimes even from someone else).
The output of these scripts is simple, currently they write into stdout something like this:
Name of thing         Desired state      Current state     Result
----------------------------------------------------------------------
THING A               This               That              NOT GOOD
THING B               This               This              GOOD
THING C               This               ?                 Timeout after 5 minutes
...

Result: 
- 2 things needs attention

My question is if there is some tool or standard targeted at this specific use case?

I have scripts, I could call them "diff calculators" that can output whether some "thing" or "subthing of thing" is in desired state and what is the current state
The tool produces nice table based UI output

**Tags:** configuration-management

> **Comments:**
> **username_1**: I wrote EXACTLY this tool, with EXACTLY the same columns, LOL, to check which microservices I need to deploy for a release.It's Gradle and ECS specific. I use ECS to get what versions are currently deployed (via AWS CLI commands), and use Gradle dependencies task to get what my desired versions are.  

---

## 2 answers

### Answer by username_0 on 2021-02-16. Score: 1

I found [Pester](https://pester.dev/) which is just a powershell unit testing that can save Nunit XML results which can be published inside the pipeline.

It's not "desired"/"current" state I had hoped for but it can in the end provide a nice overview of all the "things" whose states I need to observe.


---

### Answer by username_2 on 2021-02-16. Score: 0

This seems like the sort of thing that configuration management tools like ansible are intended to solve. You can [run ansible in check mode](https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html#using-check-mode) to see what it would do.

> **Comments:**
> **username_3**: Wow, I thought ansible was dead. It should be.  
> **username_2**: Ansible is one of the nicer configuration management systems available.  If puppet and chef are still kicking then ansible should be doing quite nicely for itself.  
> **username_3**: I've not seen a single good argument for ansible since its inception. I believe it's broken by design, is solving the wrong problem, and is even doing that the wrong way.  

---

