Moving away from Puppet: SaltStack or Ansible?

Hey. I think you misunderstood what I was trying to say.

The docs: Well, they were in a mess for a while when I started and I agree that they're really neat now.

Declining community help: I was referring to a specific ml thread that I stumbled upon when I was unhappy with the (previous!) state of documentation, wherein someone asked whether you (both the company and you as a person) would consider putting the site in git / opening it for community improvements. You declined. That doesn't mean that I judge you for that decision, it just seemed like a wasted potential at that time to me (Given: "Site in disarray" and "Free help offered"). Nowhere did I state that you don't accept community support per se.

Template: Well, the big problem might be Github's support for this 'feature'. If I want to file a new ticket [1] there's nothing helpful here. Yes, there's a rather bland "Review the guidelines.." link, but frankly I didn't click that. Why? I know how to use Github to file tickets. It doesn't say "Please read this or your tickets will be closed" or even better, just embeds the template you require in the new ticket form. While I certainly understand that you want/need some structure, the user experience is currently Not That Good.

Lag in GH response: That .. wasn't actually my point. My (random, sample) ticket was promptly active, nice people discussed it. I don't even care too much about the fact that it isn't solved after six month. I was mostly trying to point out that Ansible, for me and in my personal use cases, seemed a little unreliable and incomplete. This is one of the reasons I _need_ to use shell: or I cannot have a playbook that starts postgresql or dovecot, period. Is it important for Ansible Inc or the world? Probably not, but workarounds like these are the reason I don't like looking at my playbook anymore.

I rejected Dockerfiles because a random list of shell commands isn't what I wanted. My Ansible files are now a mix of clean/official modules and some of the very same random shell commands, and not by choice.

Let's close with:

- I appreciate your project/product. It helped me a lot (see first sentence in the gp post)

- I'm sure Ansible works great for scenarios of various sizes. I don't claim my experience is to be expected for everyone (but note that some people at least have expressed similar feelings about the 'yml files turn to shell scripts' idea)

1: https://github.com/ansible/ansible/issues/new

And salt will even output the command results for you in JSON. There's massive potential there for using salt for monitoring not just deployment.

Ah, the site in git. Yeah ansible.com (our corporate presence) being in git is unlikely to be a thing :) Nobody does that of course, but we do have the entirity of docs.ansible.com in git and that's been that way for a while - and there are github contribution links on most docs pages that aren't code generated. The ones that aren't you can edit the module source directly and the DOCUMENTATION are embedded in there.

I really wish GitHub did have template support and have asked a few times :) We've actually never auto-closed a ticket so I'll smite that comment, we never implemented it. However the template is still helpful and all that. The new GitHub issue reorg is a step in the right direction and I think they'll continue to improve it over time. We definitely could be in something like JIRA, but, ick, that's not where the users are and the barrier to entry to tickets there is high. So we're left with whatever workarounds :)

Anyway, comments are all good, hope that clears things up a bit on our end too.

Here's an article on eBay using this for Ansible based on what twitter was doing - https://github.com/search?q=stars%3A%3E1&type=Repositories&r...

I feel like every discussion of configuration management should start with what scale you are talking about. Managing 100 servers is quite a bit different than our environment which is about 7500 logical hosts on 5000+ physical servers across 5 datacenters (real datacenters, not cloud).

We looked at Salt versus Ansible and chose Salt mainly due to scaling concerns with Ansible. I believe Ansible has been addressing this, but at the time we did our evals last year it was a concern. We skipped Puppet due to DSL and Chef because we didn't want to delve into Ruby (I love Ruby, but it's not a tier-1 language for us like Python).

So far in our largest datacenter, which has 2700+ hosts, we are able to manage it with a single Salt master. That took some tuning, but it works. We have tested bringing it offline to make sure the "thundering herd" problem is mitigated.