[darklajid]

I haven't looked at Salt, but I had a love/hate relationship with Ansible so far.

To be clear: Starting with Ansible was amazing, the first couple steps were easy and enlightening. Maybe I'm expecting too much now and act entitled or something? That said, it broke down rather quickly.

- My first issue was documentation. This article is correct about the current state of the documentation, but the site was in a really bad state in limbo (between redesigns or something) for quite some time. Offers on the mailing list (Not by me) to restructure the website, as a community effort, were declined. Basically the documentation was, from this point of view, unusable before the current design went live. Broken links, no easy structure.. It was 'an adventure'.

- The bigger/biggest gripe: Everything I try to do in Ansible seems to turn into a shell script. Limitations in Ansible and the "Use a template for bug reports"/laggy response on GitHub lead to workarounds all over the place, where I had to resort to 'raw:' and/or 'shell:' where there should be a reasonable way to do things. One (of quite some) examples would be [1]: For starting random services (postgresql, dovecot in my case) Ansible just breaks and hangs forever in my environment. Ah well, let's resort to shell: service postgresql start (which .. doesn't do change tracking, isn't the same thing .. but works).

I'm really happy with what Ansible allowed me to do. I'm not satisfied with the result I have here and still look for a way to drop all my (necessary!) debug: and shell: modules for a different solution.

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

[mpdehaan2]

The docs reorg you mentioned happened Christmas of last year and most people are really really really happy with it now. We haven't done a major reorg sense or needed to, but the company was only a year old at that time, and it got to the point it needed to be done. Definitely took a while to appreciate all the different learning styles of people using the docs to find something that works for everyone and took some wrangling with Sphinx too!

I don't think it's fair to say we declined community help because one of the most amazing things we have in docs - the module docs generator that builds half the website, is a community addition. There were also various attempts to build Angular JS versions that looked crazy awesome, but the search engine problem wasn't solved at the time, so we were unable to use them.

I'm not sure why people don't like the template, but it's a common feature in Bugzilla - frankly, we spent so much % of our time asking what Ansible version was, this allowed us to service everyone's GitHub a LOT faster, and gives us the ability to work through everything so much faster and ensure better quality.

The bug template is important. As for lag in GitHub response, there's a priority system for tagging tickets, where we hit P2 items first, and then some others. Ultimately, we're devoted to stability and hitting the biggest things first, and have to avoid "hey look, a squirrel" syndrome. Part of the cost of having one of the most contributed to projects in GitHub in terms of users is does take a while to review everything and we spend a lot of time on triage.

[darklajid]

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

[mpdehaan2]

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.

[zwischenzug]

"Everything I try to do in Ansible seems to turn into a shell script"

This was my disappointment with Ansible (and other CM tools) - so why not treat the shell as the basic unit of action? See my post elsewhere on this page for more: https://news.ycombinator.com/item?id=8135823

[mpdehaan2]

This doesn't have to be the case.

All resources in Ansible are declarative models of state, that get informed, and have idempotent properties.

So it's just like any CMS.

However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :)

Also, when you want to just push and run a script versus using one of the 234 other modules, it's there - http://docs.ansible.com/script_module.html

[zwischenzug]

I don't see the point of managing state at all. If it's stateful you're doing it wrong, and likely deploying it wrong too.

And if that's the case I don't see the point of a level of indirection outside the shell script. But that might be just me :)

I talk a bit more about this here:

https://www.youtube.com/watch?v=zVUPmmUU3yY

but it's quite heavily edited and a little out of date.

[contingencies]

This comment is disturbing because it assumes there is a wrong way to do things. In fact, the point of managing state is to react to the changing state of different resources (ie. services in a service-oriented architecture, the physical or virtual systems they run on, the networks that connect them, etc.) and to automatically resolve failures through known and tested state-migrations. If you missed that, you're in no position to be calling people wrong. Further, anyone wrapping bash in python and calling it elegant is insane.

[zwischenzug]

"In fact, the point of managing state is to react to the changing state of different resources (ie. services in a service-oriented architecture, the physical or virtual systems they run on, the networks that connect them, etc.) and to automatically resolve failures through known and tested state-migrations."

They should be part of the definition of your system (ie the state), not changed on the fly.

If I said ShutIt was elegant, I was wrong (not sure where I did). It's not elegant, just as the real world is not.

Anyone trying to make config management look elegant is selling you a pup.

[shiven]

However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :)

A thousand times this! I, personally, find YAML easier to grok than whatever Puppet was using (see, post-puppet PTSD selective amnesia). And, anything that doesn't work, on a deadline, can be shell scripted now and modularized later.

[zwischenzug]

"can be shell scripted now and modularized later"

Only true if by "later" you mean "probably never".

[crucialfelix]

is CMS supposed to mean Configuration Management System ?

If so, that's a really awful re-use of a TLA (three letter acronym)

Many people still refer to any website that is editable as a CMS - Content Management Systems.

so please don't call it that, it will only sow confusion

[headstorm]

The term CMS has been used to mean configuration management system for longer than it has been used to mean content management system. One can find articles from 1990 using it in the former context, while the latter appears to have been used since the late 1990s.

[maslam]

Ansible is nice, but I share the same gripes as darklajid. Plus, with Docker taking off, I question how valuable Ansible will be going forward. I see it as a "nice Chef" or "usable Puppet". Not revolutionary.

[mpdehaan2]

I don't think we're interested in creating a revolution, but making IT practices easier and simpler and better. Which has a LOT of merit.

With regard to Docker, see http://www.ansible.com/blog/2014/02/12/installing-and-buildi...

The overlap of Ansible and Docker is pretty stratospheric in adoption levels. As more fleet management services exist, to us, it looks like another VM type, and all those cloud modules will also help orchestrate it.

But now, people are using it for both image builds and placement in great number.

[dba7dba]

SaltStack documentation is awesome. I may be biased because I am starting out with Salt but the documentation (and their website) is awesome.