Ansible 4.0

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated.<p>Having said that, this caught my eye:<p>&gt; There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details.<p>Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We&#x27;ve been using both Ansible and Puppet in my previous job, and we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would, in addition to the other &quot;usual&quot; dangers, bring along the danger of the new version not having a package for the &quot;old&quot; version of Puppet or Ansible that we were using. Which would force us to divert attention to the automation tool&#x27;s problems instead of using the automation tool to solve problems.<p>I do understand that nothing can stand still and everything must evolve and change, but at some point this acquires the flavour of changes for the sake of changes. Especially when regressions happen and things that were working perfectly are now breaking, it is not exactly pleasant to have to devote time to them.<p>It&#x27;s not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged, but the syntax of a manifest or playbook that does a couple of simple operations cannot remain stable. It&#x27;s not like those tools were created yesterday, in which case it would be reasonable to expect changes in their first years.

It was harder than I expected to find the changelog so I’ll leave the link<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ansible-community&#x2F;ansible-build-data&#x2F;blob&#x2F;main&#x2F;4&#x2F;CHANGELOG-v4.rst" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ansible-community&#x2F;ansible-build-data&#x2F;blob...</a>

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I&#x27;ve been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible within terraform. Do people really do that and is it useful? Or is it something you would only do if you have a lot of legacy infrastructure already configured via Ansible.<p>Curious on the general take here.

<i>&quot;Due to a limitation in pip, if you are upgrading from Ansible 3 (or earlier), you need to uninstall Ansible and Ansible Base before installing Ansible 4&quot;</i><p>Was it <i>really</i> a limitation in Pip? Or did the Ansible devs just really want this non-backwards-compatible release to use the same name as before, just so they wouldn&#x27;t have to use a new package name like &quot;ansible4&quot;? Even though that would allow both pre-ansible4 and ansible4 scripts to co-exist? And considering everybody has to test and update their code for ansible 4 anyway?? This seems to just cause more pain for devs and admins with no real benefit. Which is to say, par for the course.<p>This is the main reason I have always hated using Ansible. Arbitrary decisions leading to a cumbersome, bloated, undocumented, difficult mess.

Their versioning is unnecessarily confusing. Why call it version 4 and then when you run --version it shows a different version?<p><pre><code> $ ansible --version ansible [core 2.11.0] $ python -c &#x27;from ansible_collections.ansible_release import ansible_version; print(ansible_version)&#x27; 4.0.0</code></pre>

&gt;<i>Due to a limitation in pip, if you are upgrading from Ansible 3 (or earlier), you need to uninstall Ansible and Ansible Base before installing Ansible 4:</i><p>Does anyone know what they&#x27;re talking about? This is a pain to deal with in my app, and I&#x27;ve never seen it with any other pip package.

Pretty cool but Ansible just seems too slow to me. I&#x27;m just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.

Is there any big improvements or whats the benefit of porting to Ansible 4 (other than it seems Ansible 3 is EOL&#x27;d now)

Link to previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27215477" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27215477</a>

This broke us. Some crap about sftp. Three hours down the drain.

Does anyone use Ansible in GitOps ? If so, what other tools do you use? Gitlab? Other? If not, what would you recommend for non-Kubernetes infrastructure for GitOps?

Is there any open source alternatives to Ansible, Terraform, Chef, Puppet, etc?

Ansible is under the GPLv3 but they say this doesn&#x27;t apply to your .yml files because those are data, not code.<p>I think they&#x27;re interpreted code. The yml has steps which aren&#x27;t too different from statements.<p>If what the project creator says matters, the GPL has less legal meaning.<p>I personally think the GPLv3 does protect more than just compiled code, and that Ansible is off their rocker with the GPL.

I always cringe when I read the word &#x27;final&#x27;. :)<p>Too many years in the industry with projects called final... Basically a tag saying &#x27;this shit ain&#x27;t never gonna be over! Run for the hills!&#x27;.<p>And nothing is more set in stone than a bunch of yml ;) &#x2F;s