[headwayoldest]

I understand the desire to flee Ansible before the IBM shittification completes, but anything based on Salt is not the way.

Needing a "master" node that can lose sync or orphan managed nodes it forgets about is a show stopper for any project with meaningful hardware churn.

[techdragon]

Not sure where the dislike comes from, when all configuration management tools have issues with "orphaned nodes". I've even have small bugs/misconfigurations in fully push/declarative setups with Terraform packages where they stopped identifying updates correctly. If anything, with a push tool like Terraform reporting that it did what it planned on doing successfully, its arguably easier to not notice something has been orphaned since you won't have any signal back that something is "wrong", an orphaned configuration node has nothing to do and therefore is already "correct". Salt may have its flaws, but I find it hard to argue that "orphaned nodes" is any more of a flaw of salt than it is of cfEngine, Chef, Ansible, Puppet, Terraform, Helm Charts, Kubernetes Operators, or any other "configuration management tool".

Also... Salt does have High Availability options, https://docs.saltproject.io/en/latest/topics/highavailabilit... with Replication/Failover and Multi-Master modes, and there's also "Syndic" which break up how much each master is responsible for in order to create failure domains or separate responsibilities between stacks of infrastructure like having one per datacenter... oh and the underlying data stores that masters and syndic daemons rely on can be setup with highly configurations since you can keep the cached data in Redis, Consul, EtcD, or MySQL...

Salt is a bit complicated, but just can't understand where you're coming from here. I've never used a configuration management system that wasn't a bit complicated in one way or another, their job is to be the sin-eater of the complexity that is inherent in managing computers and software.

[OJFord]

I'm not at all a fan of Ansible but I must have missed something here - has IBM somehow bought/taken over Ansible?

[mdaniel]

IBM -> RedHat -> Ansible (https://docs.ansible.com/platform.html)

I think the new ansible docs are opaque, and the new "everything is an ansible collection" scheme makes troubleshooting any issues reported by users hundreds of times harder than "the old days"

I keep this (https://github.com/ansible-community/ansible-build-data/blob...) bookmarked because it's the only way to match up what "ansible 8.1.0" (https://pypi.org/project/ansible/8.1.0/) even means since it for damn sure not any of this: https://github.com/ansible/ansible/releases (they used to have a 'release' pinned on that releases tab saying "these are not the droids you are looking for"). I believe I tried asking for them to update the completely erroneous pypi "source code" link to point to that repo and ... well, one can see how well that turned out

[bravetraveler]

Has something happened to the ansible-doc command?

This has behaved the same for me for years, but I use distribution packages so may lag behind a bit.

[raju]

IBM acquired RedHat who made Ansible. I believe that’s what the parent comment is alluding to.

[p_l]

Red Hat owns commercial side of Ansible and Red Hat was acquired by IBM

[brazzledazzle]

RedHat owns Ansible and IBM owns RedHat.

[nubinetwork]

There is also foreman/katello