Ansible 4.0 • Hacker News Board

Re: Ansible 4.0

#51

Post by binoct » Thu, May 20, 2021, 2:37 AM UTC

colechristensen wrote: post #31

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use. You ended up with lots of magic an internal domain knowledge about how to d…

> You ended up with lots of magic an internal domain knowledge about how to do things, and often had to get clever to get the result you wanted.

How does Kubernetes not also result in the same? I'm not questioning plenty of improvements and the somewhat different domain it brings to the table overall but genuinely curious. From what I've seen any tool designed to integrate and manage complex, disparate systems is going to end up with lots special cases, domain knowledge, and require digging into implementation details on a regular basis for anything other than absolute common-case uses.

Re: Ansible 4.0

#52

Post by [deleted] » Thu, May 20, 2021, 2:38 AM UTC

geodel wrote: post #49

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

I am not much familiar with Ansible/Puppet etc. However working in Java and dealing with frameworks like Spring/boot, kafka etc I notice a phenomenon of large number of breaking changes, specially when one update in couple of years as opposed to update with every release. Now when I dig into changes it just points to extremely poor design to begin with. It just couldn't handle slight change in requirement without bre…

[deleted]

Re: Ansible 4.0

#53

Post by tundrax » Thu, May 20, 2021, 2:40 AM UTC

colechristensen wrote: post #31

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use. You ended up with lots of magic an internal domain knowledge about how to d…

Ansible, chef etc. are provisioning tools, not container orchestrators.

Re: Ansible 4.0

#54

Post by jacobsenscott » Thu, May 20, 2021, 2:41 AM UTC

AJAlabs wrote: post #21

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

With verison 4.0.0, they've implemented semantic versioning which should make life easier for avoiding breaking backwards compatibility changes. https://semver.org

All semver does is tell you you are pinned to some obsolete tool, and you are going to go through a soul sucking 6 months of yak shaving to stay up to date. (rails programmer since v3 here)

Semver doesn't make life easier. Making backward compatible changes is what makes life easier.

Re: Ansible 4.0

#55

Post by taneq » Thu, May 20, 2021, 2:41 AM UTC

kbenson wrote: post #34

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

> It'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's clear when you deal with both types of systems. Perl optimized for stability and backwards compatibility at the cost of new features and new language conveniences. This is great and a st…

There seems to have been a strong swing in the past decade or so towards busywork being not just acceptable but in some way laudable. "Doing the work" to keep your product using all latest versions is noble, whether or not you actually gain anything by upgrading. I can't shake the feeling that it all ties in to the industry wide push for SaaS and subscription models and evergreen software, all of which share an underlying motivation of everlasting job security for software companies and the people who work for them.

It's a similar attitude to the parts of the OSS community who feel that anyone complaining about poor documentation or usability just "doesn't want to do the work" to understand the system.

Re: Ansible 4.0

#56

Post by tundrax » Thu, May 20, 2021, 2:43 AM UTC

zmmmmm wrote: post #12

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I'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 wi…

We do use ansible for provisioning in combination with AWS CDK. The cases are simple as when you don't utilize container services, but roll out your own server infrastructure using EC2.

Re: Ansible 4.0

#57

Post by tundrax » Thu, May 20, 2021, 2:46 AM UTC

encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'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.

Puthon doesn't seem to be the performance issue here, but remote operations on target hosts.

Re: Ansible 4.0

#58

Post by candiddevmike » Thu, May 20, 2021, 2:47 AM UTC

purpleidea wrote: post #22

encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'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.

Um, you've seen https://github.com/purpleidea/mgmt/ right ;) Join us!

Red Hatters keep leaving the company and building config management tools =D.

For mgmt, I don't see anything particularly novel that it brings to the space. It doesnt use YAML, but if I'm going to write pseudocode I may as well reach for Pulumi or python. Why would you recommend mgmt over Ansible or Terraform? Since this can use Consul, why wouldn't I just use Consul for event driven changes?

Re: Ansible 4.0

#59

Post by zymhan » Thu, May 20, 2021, 2:51 AM UTC

tundrax wrote: post #53

colechristensen wrote: post #31

Earlier quoted context omitted.

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use. You ended up with lots of magic an internal domain knowledge about how to d…

Ansible, chef etc. are provisioning tools, not container orchestrators.

The point is that had they worked well, containers may not have become as popular as they are now.

Containers are only somewhat used for scalable microservices. They're mostly just an easier way to deploy software than creating your own RPM package and using orchestration tools to deploy it on VMs.

Re: Ansible 4.0

#60

Post by m463 » Thu, May 20, 2021, 2:54 AM UTC

colechristensen wrote: post #31

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use. You ended up with lots of magic an internal domain knowledge about how to d…

I've found that every new technology that solves problems, also comes with its own set of problems. :)