
Moving away from Puppet: SaltStack or Ansible? - mikebike
http://ryandlane.com/blog/2014/08/04/moving-away-from-puppet-saltstack-or-ansible/
======
mpdehaan2
Hi ansible author here!

This was definitely an interesting comparison but to correct a few
misconceptions:

Ansible has 810 contributors at this point. I'd love to say I wrote everything
but it's a huge shared effort.

We also have a lot of mods other projects don't, so some comparison aspects
were not even.

We do say no when we disagree. I think that's important. Filtering and testing
makes a project what it is to a degree. There is always the project and
development list to discuss things and they are really big lists. All being
said not transferring a file verbatim is for example still the right call for
us.

Try what you like by all means! But I would suggest that it not be inferred I
eat children :). Only sometimes!

~~~
willthames
This seems illuminating.

"The only complaint that I have here [about Salt] is that they are sometimes
less rigorous than they should be when it comes to accepting code (I’d like to
see more code review)."

Keeping high quality across a project requires discipline. And that discipline
can sometimes seem cold.

"pull request welcome" is at the warm end of the spectrum.

~~~
geerlingguy
And in my experience, submitting a well-reasoned, simple pull request to add a
small change or fix a bug always results in a merge.

As someone who also maintains a few (much, much smaller) OSS projects on
GitHub, I really understand the 'no' mentality. It's often much harder to say
no, but usually I try to put it in a positive way (yes, this is a worthwhile
idea, yes, it looks like it could help in this situation, but no, I won't be
merging it because I don't think most of the project's users would benefit
from its inclusion).

~~~
mpdehaan2
Yep, we definitely try to.

Part of the difficulty comes from the dynamic changes of GitHub. 10 years ago,
usually folks would discuss a change prior to submitting code.

Now, it's more common for someone to assume code is wanted, and then it's easy
to be a little disappointed when you find an upstream would want it implement
differently.

In all though, GitHub has done wonders for standardizing contribution
processes.

------
mmerickel
It's unfortunate that this article focuses on running the playbooks/salt
states locally. The use of ssh by ansible was the killer feature for me.
Configuring a remote cluster without requiring a persistent master. There are
valid arguments for maintaining a persistent master, but it's just not in the
cards sometimes.

I know salt-ssh exists but it's still alpha, I look forward to seeing how it
pans out and whether it can avoid being a second-class citizen to the
persistent, non-standard zeromq sockets.

That being said, ansible configuration files are fairly hacky and conceptually
just don't quite fit. Some modules support a full yaml-dict whereas others
need the string with key=value parts. Sometimes you need to wrap your jinja2
syntax in a yaml string to avoid it being parsed as a yaml dict. There's just
some things that don't quite add up so there's definitely room for
improvement.

I think I'll live with it until I gain confidence with nix though!

~~~
ryan_lane
I'll follow-up with a post about how we're working without a master. We need
neither SSH, nor a master.

We're very heavily using autoscaling, which makes SSH a no-go. Ansible has
Tower for this, but it's proprietary. We /could/ use a salt master for
autoscaling, but we prefer masterless in this situation because it scales
better.

~~~
mpdehaan2
ansible-pull is available for those that need to invert the architecture,
though we're finding most users in companies who need autoscaling can afford
Tower. Price points are definitely important in that regard, but ansible-pull
does exist for those that would rather go the pure OSS route.

Tower is also free for up to 10 nodes. See my comments above about why we went
that route - being able to build products versus having to become a
consultancy or support outfit makes it easy to keep ansible to be easy to
understand and rock solid, and most people are quite happy with that split.

~~~
ryan_lane
Open core also has its set of issues. For most open core products I've used
over time the community starts creating alternatives to the proprietary
products and the upstream slows its acceptance of open code. The upstream will
also tend to spend most of its time working on proprietary features.

Whether or not tower costs money, it's still a worry of being a single point
of failure for autoscaling, which is part of why we avoided masters.

~~~
mpdehaan2
We've never held back anything from Ansible, really. Rather, Tower is more of
a product on top that provides some extra enterprise features that most of our
user bases don't need (but they should try it, because they might!).

I think if you see things like Windows being part of Ansible proper, it's
clear we're not holding that back. But there are also tools the OSS community
can't build easily, things that involve coordination around database schemas
and (ick!) status meetings and UX mockups.

Yes, communities can build them, but occasionally, just occasionally,
companies can build them better. And this is one of those cases. Our business
model basically funds Ansible and also makes Tower significantly more capable
that way, and it only becomes something you need when you can afford it. And
it's not so much because we're a company, because I've got tons of awesome
folks working in 100% full time, and that's a lot of power to build good
stuff. Most likely your company employs a few folks as well :)

So on the "open core" comment, Ansible won't, for instance, ever have
proprietary modules. That's something we said we don't do. Ever.

As for Tower, the small guy isn't going to need it yet. He's probably ok with
pure Jenkins fronting the show. The big guy probably needs it and a super-
well-tested environment and a guy to call when it has issues.

I don't know anything about other communities you've been a part of, but I
think our track record shows what goes where and people are comfortable with
it. Ansible isn't open core. It's the real deal. We take that seriously.

Yet, I think the general assumption that all software has to be purely 100%
open is flawed, but that in general, open source communities can build some
things in GREAT fantastic ways, and certain layers do benefit from being free
software. But companies need to exist. Including yours! (Though I do love me
some Uber).

Anyway, ansible-pull is indeed an option if you wanted to go that wrote, or
even doing image builds with Packer. Both popular options for immutable
systems and/or autoscaling, sans commercial bits.

But is commercial software dirty? Heck no. Ask any SaaS company :)

~~~
icebraining
_But is commercial software dirty? Heck no. Ask any SaaS company :)_

The pedantic in me feels compelled to point out that commercial SaaS doesn't
have to mean closed; the company I work for is a good example, where our
products and service are based on an third-party AGPL licensed software called
Odoo[1] (and are therefore AGPL licensed themselves).

In any case, we do use Ansible here, and are happy with it :)

[1] [https://www.odoo.com/](https://www.odoo.com/)

------
zhynn
While I have been a happy Ansible user for some time, the criticisims that the
author pointed out that really resonated with me were:

\- Ansible is slow even when it doesn't have anything to do. This is true. For
example, we manage lists of former users that should not exist on systems,
this gets quite slow. I think that the slowness is mostly due to SSH, but it
could be smarter about bulk operations, I suppose.

\- Custom DSL looping and conditionals. This was intended to make the system
simpler and easier, but I agree with the author that I also have to revisit
the documentation since looping in a template (jinja) is different than
looping in a task (with_ directives).

\- Task variable registration opacity. Yup, lots of debug: actions.

People in IRC are pretty friendly, but I did get a tone of "you're doing it
wrong." This is exemplified, I think, by the author's "global ignore_errors"
feature request. I made a suggestion that ansible-playbook should be able to
run a role without having to create a stub playbook that calls the role. I
ended up creating a bash script for it, but the response on IRC was in the
vein of: I don't use it that way, you are doing it wrong. To me, Ansible is
another tool in my sysadmin chest, I am going to use it in the way that works
best for me. It's nice if the tool supports my workflow.

The remarks about the friendliness of the Salt community are enough to get me
to take another look... Oh, and also that Salt released its webUI (Halite) to
the community, but Ansible's AnsibleWorks is closed. A UI can go a long way
towards increasing usage.

It's lightyears better than Puppet/Chef, and I am glad both exist. :)

~~~
vacri
If you think ssh negotiation is the slow point with ssh, have a look into
'persistent connections'

The below is an example setup of a session that persists for ten minutes after
last logout. Subsequent ssh attempts (or new parallel ssh attempts) will
piggyback onto the session and avoid the renegotiation delay.

    
    
      host *
        ControlPersist 10m
        ControlPath ~/.ssh/master-%r@%n:%p
        ControlMaster auto

~~~
ryan_lane
Hi. I'm the blog post author. The issue isn't SSH. I was running ansible-
playbook on the local system using -c local. It wasn't using SSH at all.

------
wldlyinaccurate
Everybody seems to be taking about moving away from Puppet lately. Maybe I
just don't do anything sufficiently complex with it, but I've never had any
problems or gripes with Puppet. 99% of the time it seems like the thing I want
to do has already been done in a well-written module on the forge.

The author seems to cite two main reasons for wanting to move away from
Puppet: their codebase was large and badly structured, and their techops team
didn't know Puppet well enough to manage it. Neither of these sound like
problems with Puppet itself -- they're certainly not unique to Puppet. I'm not
convinced that moving to a newer, less mature technology (which I assume
techops don't know well either) will solve these problems.

~~~
ryan_lane
There's definitely more reasons. I didn't want to detract too much from the
topic of the blog post when I wrote it, since the post is already obscenely
long.

Puppet doesn't have native support for a lot of things, which require us to
either implement it in puppet's DSL, or in custom ruby, which the upstream
won't take. For instance: git, gems, pip, virtualenv, npm, etc. etc..

Puppet doesn't have looping. I'm always told: "Iteration is evil. Puppet is a
declarative language and if you're needing to loop you're doing something
wrong." But it's simply not true. Looping making things insanely simpler.

Puppet isn't executed in order, even for the same service in the same
environment across systems. You have to very diligently manage every require
for ordering, and no one does it right. This had lead to systems unable to run
first runs really often, which causes problems with autoscaling. I don't enjoy
spending my time cleaning this up often.

Puppet's DSL is full of little gotchas that constantly cause issues for
developers who aren't very familiar with Puppet.

Half of our team was very familiar with Puppet. If you look at my blog, quite
a few of the older posts are about Puppet. I worked on the puppet
infrastructure at Wikimedia Foundation for a long time, and released all of
the puppet code as open source (they have 60k+ lines of puppet).

~~~
ahpook
I'm a little sad because most of these issues (as I understand your
description them) are already fixed or well underway :( It's probably too late
for your specific case but I'd like to reply anyway since a lot of this is
"conventional wisdom" based on old information. Full disclosure: I'm the
product owner for Puppet and before I worked here, I ran it in large-scale
production since 2008.

Not quite sure what you mean by 'native support', but gem and pip package
providers are built-in. there are high-quality modules for git (puppetlabs-
vcsrepo), virtualenv (stankevich-python), npm (puppetlabs-nodejs), etc -- it's
a design decision to move much of this into modules and out of core so they
can iterate faster.

Totally agree that loops make many language constructs much easier, and
there's looping in the rewritten parser --
[https://docs.puppetlabs.com/puppet/3.6/reference/experiments...](https://docs.puppetlabs.com/puppet/3.6/reference/experiments_lambdas.html)
\-- which will be on by default in the next semver major.

While the model definitely wants you to describe relationships between
resources if you need to send subscribe/refresh messages, there's toggle-able
ordering algorithms that will let you run them in manifest order -- I blogged
about it here: [http://puppetlabs.com/blog/introducing-manifest-ordered-
reso...](http://puppetlabs.com/blog/introducing-manifest-ordered-resources)

The parser and evaluator are undergoing a total rewrite to be an expression
based grammar, which is explicitly to make better definition around the
language and eliminate the gotchas --
[https://docs.puppetlabs.com/puppet/3.6/reference/experiments...](https://docs.puppetlabs.com/puppet/3.6/reference/experiments_future.html)
(this will also be the default on the next semver major)

\--eric0 / @ahpook

------
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](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](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.

------
_Soulou
I read that for some of you the Chef experience was painful. I'm using chef-
solo with the chef-solo-search cookbook and everything is working pretty
fluently. Each of my node owns the entire repository and apply chef-solo on
itself. With a cron to periodically update the chef repository, it is really
confortable.

I agree that using chef-server is a bit painful (that's why I don't), but
otherwise there are a lot of cookbooks and it works well. What kind of bad
experience did you get?

~~~
unkoman
The documentation is sub-par and rarely updated. Otherwise, it's nice,
especially in AWS.

------
sandGorgon
I wish that Ansible would work with orchestrating Docker containers.

Here's my thought - Docker is replacing the use case for using
Ansible/Chef/Puppet for a lot of people. It is far too easy to build portable
docker machines and deploy them on bare metal. For me, the use case of
provisioning a softlayer server and then setting it up using Ansible/Chef is
no longer present.

However, the problem of orchestrating _a bunch_ of Docker machines is still
unsolved. I was hoping that Fig would solve it, but by their own admission
[1], Fig is going to be closely tied to Orchardup and not intended for general
use.

So, if I want to launch a hadoop cluster over 20 Docker VMs, physically hosted
in 5 different servers... I really have no way today. Notice, that the
complexity includes setting up bind-volume mapping, logging, passing of
variables from one Docker VM to another, etc.

I'm not sure if Chef is more suited to this, given that Octohost moved from
Ansible to chef for a Docker PAAS [2], but I would definitely love for Ansible
to do this part really well !

[1]
[https://news.ycombinator.com/item?id=8075705](https://news.ycombinator.com/item?id=8075705)

[2]
[https://news.ycombinator.com/item?id=8086092](https://news.ycombinator.com/item?id=8086092)

~~~
carlivar
"the problem of orchestrating a bunch of Docker machines is still unsolved."

I don't know about that.

Mesos was already mentioned:
[http://mesos.apache.org/](http://mesos.apache.org/)

There's also Kubernetes which has recently started working on Fedora and
CoreOS:
[https://github.com/GoogleCloudPlatform/kubernetes](https://github.com/GoogleCloudPlatform/kubernetes)

And there is CoreOS's fleet system, although this is more low level and would
still need orchestration:
[https://github.com/coreos/fleet](https://github.com/coreos/fleet)

~~~
ryan_lane
Kubernetes is built using SaltStack :)

~~~
sandGorgon
interesting !

I didnt know that, but this confirms it -
[https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md#gce-
cluster-configuration)

------
ransom1538
I probably am dating myself here. But with cloud infrastructure what is the
point of these configuration management tools? To get the configuration of an
instance just fire up a copy of instance. To install something new, have a
script install it on one manchine - monitor it, then start deploying it. You
have versions of instances, backups, and exact copies. If you want to push, it
is 10 lines of bash with a git pull and ssh public keys. AWS has an amazing
API. I have seen guys try these 9k+ lines of complex syntax Salt systems only
to break things, misconfigure them, and leave the system totally dependent on
the author (aka the genius). We have ran systems of 100+ machines with a few
lines of bash - so I am blown away at this new complexity. PLEASE help me out.

~~~
geerlingguy
This is also more of the 'containerized'/Docker-like infrastructure
development workflow.

Tools like Ansible and SaltStack also provide pretty robust infrastructure
orchestration/management tools that are conveniently provider-agnostic. I save
a ton of money by spreading out servers for one particular service over a
bunch of lower-cost providers (rather than AWS), and use Ansible to manage
them all.

If you play in one particular cloud infrastructure, image-based configuration
and provisioning may work fine, but if you need to support the movement of
images from developer workstations through to different hosting providers
(whether using Docker, CM, or bash scripts), Ansible can help with that (as
can Packer, Terraform, etc.).

------
fred_durst
_> I did get a “pull request welcome” response on a legitimate bug, which is
an anti-pattern in the open source world._

Can someone explain why this is an anti-pattern? Is there some sarcasm I'm
missing? Seems like exactly the kind of response I appreciate when I submit
issues in open source projects.

~~~
cheald
"Pull request welcome" usually means "This is a legitimate bug, but I don't
care enough to fix this for you."

Some people believe that maintainers should fix all bugs that are reported to
them. Other people believe that the open-source nature of the software should
cause people to fix their own bugs and contribute the fixes back to the
project, and both camps often believe that demands on their own time and
effort are unreasonable.

~~~
staz
This is not a problem of entitlement where people expect that you fix their
bug for them. This is an anti pattern because many people consider this type
of answer rude and it doesn't create a welcoming community.

Saying "This is a legitimate bug, but I don't care enough to fix this for
you." is already an order of magnitude more polite than "Pull request welcome"
or the older "Patch welcome" , explaining in details why and if necessary how
open source work even more so. You have to remember than not every one know
the Open Source community speak. If you can guide the reporter on how to
create said pull request, even better.

Yes its take more works and it's less fun than hacking at code, but building a
great community is a lot of works. It's also, for me at least, what separate
good projects from great ones

~~~
mpdehaan2
Yeah, but it's not the same thing.

This is a legit bug results in the bug staying open.

Pull requests welcome is "I feel this is a feature, but we'd be open to you
working on it".

I think one of the great tragedies of the internet is people assuming people
say things they don't mean.

And yes, building a great community is a lot of work, and it's something we
spend a TON of time on. And it's why we have one of the most contributed to
projects on Github.

Getting to 810 contributors is really hard, and you don't do it easily :)

------
peterwwillis
Two things:

 _> The DevOps team felt that the Puppet infrastructure was too difficult to
pick up quickly_

Uh. I hate to break it to you, but rewriting your infrastructure from scratch
isn't quick either.

 _> Code should be as simple as possible. Configuration management
abstractions generally lead to complicated, convoluted and difficult to
understand code._

All code becomes complex over time if you do something different with it.
Refine your abstractions instead of throwing out code. Or use more composable
components instead of writing new code.

Finally i'd add that before you throw out a thing, your main concern should be
"is there something we cannot do with the existing thing?" There will always
be a better wheel, but if your existing wheel works, you should probably stick
with it.

------
KaiserPro
Having deployed salt to a medium sized cluster ~1500 farm machines, and around
1500 desktops, the one thing that salt won't do is scale.

Salt has a lovely system where clients attach themselves to a zeromq and
listen for commands. However after about 500 clients it starts to fail
silently and not all clients update properly.

The way we get round it is to run salt-call on the client at specific
intervals. The other annoyance is that is horribly slow (60 seconds plus to
run 100 ops (excluding yum operations))

having said that, the YAML syntax with optional python extensions is grand.
Whether its quite ready for mainstream adoption is another matter. It sort of
works for us.

~~~
mianos
I would post a bug report. I know linkedin has over 10k nodes with saltstack.
Thomas was there tuning it so I'm sure it should work.

~~~
KaiserPro
its something they know about. The current workaround is multiple masters,
which isn't entirely practical

~~~
ryan_lane
Wikimedia runs 1,000+ nodes on a really small box. No need for multiple
masters. Just increase your worker threads.

------
mlieberman85
Personally a fan of Ansible, but I've also been pretty impressed by SaltStack
as well. Either is much simpler and easier to use than the older generations
of configuration management tools (cfengine, Puppet, Chef.)

~~~
anko
I've never heard of ansible being referred to as a new generation. What do you
think defines this generation? I use puppet and chef a fair bit so I'm just
curious on the new features offered.

~~~
dcosson
My take is that this "newer generation" of tools seems to focus on combining
configuration management with orchestration. Chef and Puppet let you define
the static state of the world but leave it up to you to figure out how to
transition when something needs to change.

On the other hand, Ansible works well as simply a remote task runner (like
Fabric). Salt is the one I have least experience with, but I had a
conversation with the creator once and he seemed excited about the
orchestration possibilities with Salt. If I understand correctly you can react
to events that get triggered either manually or based on a condition on some
other server you're managing. So both of these tools make it easy/natural to
do something like run a rolling restart of a group of servers.

~~~
mpdehaan2
I'm not finding the new generation term particularly meaningful.

One thing that was somewhat unique about Ansible was it was designed for
rolling updates as the initial use case, and the desire to solve deployment
problems rather than just CM problems.

Everybody tends to view orchestration differently, so see our take:

[http://www.ansible.com/blog/orchestration-you-keep-using-
tha...](http://www.ansible.com/blog/orchestration-you-keep-using-that-word)

and

[http://www.ansible.com/blog/2013/11/29/ansibles-
architecture...](http://www.ansible.com/blog/2013/11/29/ansibles-architecture-
beyond-configuration-management)

Ultimately, for us, it meant boiling back a lot of things to base concepts,
and taking parts we liked from a lot of different things.

But is there a generation? I don't think so.

Some models make things a bit more or less flexible, or allow different
capabilities.

~~~
dcosson
Yeah that sounds reasonable. Thanks for the orchestration link, I hadn't seen
that post.

------
akurilin
We've been very happily trucking along with Ansible the past year or so over
here at Front Row. Tried Chef for a few weeks, hated every moment of it,
switched to Ansible and it all made complete sense.

For us Ansible takes care of configuring the various types of machines we have
in AWS, of building, testing and deploying binaries, of configuring and
keeping our development environments in sync and more.

It's pretty exciting that the project keeps getting better with every version.

------
eff
I've been using SaltStack + SaltCloud in a production environment for the past
six months or so -- it's been a total joy compared to my experiences with
Puppet / Chef.

~~~
magnacartic
Indeed! I've been using Salt in production since January and I haven't missed
Puppet/Chef too, even though the initial learning curve was steep.

------
hijinks
We are moving from puppet to salt and I'm half way through and so far my git
commits looks like this over the past month

puppet repo -14000 lines salt repo +1600 lines

What it really comes down to is salt has a ton of built in modules while
puppet the old way to do it was add it as a module in your main module search
path which for us was in our repo

------
ef4
I'm very happy with Ansible. Salt looks good too.

Too many of the other alternatives seem to be focused on the easy part of the
problem (running commands on lots of nodes) without putting enough effort into
the hard part of the problem (automatically deciding which commands to run to
get to the desired state).

------
cweiss
It would have been interesting to see them add Puppet to the list of tools to
evaluate (while doing their best to do so objectively as 'new users'). It
seemed to me like most of the issues they'd encountered were self-inflicted,
rather than the result of using Puppet specifically?

------
duebbert
Interesting to see that Salt seems to have a slightly higher following here
compared to Ansible.

I'm managing around 10-15 servers only but after having it all set up with
Salt for the last year, I am now migrating it to Ansible despite it being a
big hassle. I find it much more straight forward and am happy with the
documentation so far.

Salt has bitten me twice in that after (non-master) server updates commands
would fail with non-descriptive error message. I reported it as bugs but got
too frustrated in the end and decided that with a new server I will start a
migration to Ansible.

Very happy so far even though I do see the problems of speed (haven't
investigated tuning it) and that it seems to require too many shell work
arounds. But conceptually it seems much cleaner to me.

~~~
mpdehaan2
Not sure on trends, it's hard to say.

I think this is probably accurate-ish:

[http://www.ryan-williams.net/hacker-news-hiring-
trends/2014/...](http://www.ryan-williams.net/hacker-news-hiring-
trends/2014/august.html?compare1=ansible&compare2=saltstack&compare3=puppet&compare4=chef)

Definitely investigate the tuning options. ControlPersist + pipelining does
awesome wonders. We have pipelining off by default for max compatibility just
so nobody gets stuck on an initial install, but feel free to stop by the list
if you have questions.

Using "with_items" on yum/apt transactions also saves giant loads of time
keeping things in single transactions.

[http://www.ansible.com/blog/ansible-performance-
tuning](http://www.ansible.com/blog/ansible-performance-tuning)

------
zimbatm
I have used Ansible 6 months ago and it felt slow.

The biggest issue which is intrinsic to the model is that each task is
executed sequentially across all the target hosts. It makes it's behaviour
easy to understand but it also makes each step as slow as the slowest host.

Another issue that might be fixed now is that each task is essentially a
script uploaded to the target and then executed locally. Unfortunately at the
time the scripts weren't cached properly so N invocation of the same task
would mean N uploads of the same script.

That being said it's really simple to use and I recommend it if you don't have
an existing infrastructure management system. Ansible fits in well as an
orchestration tool.

~~~
mpdehaan2
Hi zimbatm,

Please read the tuning article on the blog for sure. It's definitely not slow
and we have folks updating 5000 servers in 5 minutes. (Yes, really!)
ControlPersist and the like are key, and we'd be happy to help discuss options
for you.

As for sequentially, set --forks to control parallelism. Steps are executed in
order, but that's true of all CMS systems.

~~~
zimbatm
> It's definitely not slow and we have folks updating 5000 servers in 5
> minutes. (Yes, really!) ControlPersist and the like are key, and we'd be
> happy to help discuss options for you.

It's good but I wouldn't describe this as fast, it should be possible to
increase the performance by another order of magnitude with some optimisation.
Web servers can easily serve 5000 request per second even when SSL is
involved, why couldn't Ansible do the same ?

After enabling ControlPersist, the next optimisation is to run Ansible in the
same datacenter. Latency is a killer when deploying to us-east-1 from Europe.

> Steps are executed in order, but that's true of all CMS systems.

It's true on a single host (although puppet's and salt's ordering is not
guaranteed). Ansible also orders across all the hosts. If you have tasks
A->B->C, ansible will first run A on all the hosts and collect the results
before moving to the next step. Each step is thus as slow as the slowest
execution.

------
serverascode
I remember initially looking at the saltstack docs and deciding, like the
author of the post, that they were extremely dense at first glance. It's
interesting to read that after he'd used salt for a while the dense
documentation was useful.

------
dgallagher
Does anyone have experience using Configuration Management software in a
heterogeneous environment? For example, I've seen large environments running
Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux
including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the
ugly?

I understand consolidation and standardization of operating systems is usually
the best state to be in, but in a lot of larger companies running legacy
software it's not economically feasible to do.

~~~
bkeroack
We are very heterogenous--something like 60/40 Windows/Linux split.

Traditional Windows folks don't really use configuration management or even
have any clue about it. Or at least that's my impression. I'm a Linux guy and
have been fighting a one-man battle to CM-ize our infrastructure. I have no
interest in using Microsoft's DSC on the Windows side (their brand-new CM-like
solution in PowerShell) and something else on the Linux side, and since I'm a
Python developer I gravitated to Salt.

I love SaltStack (no real experience with Ansible). Although it supports
Windows in a sense, it's very rough around the edges. Many modules will fail
or have weird edge cases on Windows. I've gotten to the point where the only
module I really trust to work 100% of the time is cmd.run (which executes
arbitrary shell commands). That said, it's been a total win so far. I've
almost completely replaced ad hoc Windows server provisioning with version
controlled, documented Salt states. It's glorious.

~~~
mpdehaan2
Here's a blog about Ansible windows support for those interested:
[http://www.ansible.com/blog/windows-is-
coming](http://www.ansible.com/blog/windows-is-coming)

1.7 comes out this week, and we're going to continue to improve it in 1.8.

~~~
volume
I'm eagerly awaiting when the SSL cert setup is more streamlined and maybe
encapsulated if possible?

I could hack away at the powershell that MS makes available but if you guys
are going to put work into it, I will wait even more eagerly for it.

~~~
mpdehaan2
We recently updated the docs to point to a new setup script you might not have
seen yet -
[https://github.com/ansible/ansible/blob/devel/examples/scrip...](https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1)

But yeah, stop by the -project or -devel list if you have questions or ideas
for it, that would be great!

------
wldcordeiro
Interesting article but the design of the site made reading it give me a
headache. I recently also made a move as well, went from Chef to Ansible and I
am really happy I did. Chef was a pain.

~~~
otoburb
We're soon going to be evaluating various configuration management frameworks.
Could you outline a few points why Chef was considered a pain?

~~~
wldcordeiro
My major pain point was the complexity of Chef Cookbooks in comparison to
Ansible Playbooks. I could hardly wrap my mind around how to write my own
Cookbooks after exploring some of the ones I used (Ruby, rbenv, Git, Nginx.)
Another major thing for me at least was the documentation, it seemed like
Ansible had better documentation to me vs Chef. Finally another thing was the
product offerings of Chef vs Ansible. Chef has some paid versions that offer
more features, whereas Ansible is feature complete for free and they offer a
GUI and Support instead which I preferred.

~~~
otoburb
I'll be on the lookout for these items in the evaluation results. Thanks!

------
buro9
I look for two things when considering configuration tools.

1\. How does it handle cross-cutting concerns?

2\. How does it handle complex configuration files?

For the cross-cutting concerns I use the firewall as an example. I look to see
how multiple projects and modules (that are going to be installed on a
machine) can declare their firewall rules.

I'm a Puppet user presently, but a quick look says that Ansible has great
firewall support (
[http://docs.ansible.com/ufw_module.html](http://docs.ansible.com/ufw_module.html)
) in a nice tight format, and SaltStack has iptables support in a more verbose
format:
[http://docs.saltstack.com/en/latest/ref/states/all/salt.stat...](http://docs.saltstack.com/en/latest/ref/states/all/salt.states.iptables.html)

On the complex configuration files, I usually consider Nginx and how to define
multiple SSL certificates, SSL ciphers, load balancer backends, multiple web
sites, and rules for locations on those websites.

On Nginx... perhaps I'm lost in the docs but beyond simple installation I
don't see either attempting to handle the config files. Is it the case that
one should deploy their own config or write something to define the config
from templates? I must be wrong on that, but lack of clear and deep
documentation on how to configure Nginx would mean I touch neither and stay
with Puppet.

~~~
wernerb
Any (configuration)file can be installed and/or templated with both Ansible
and Salt. This includes whatever Nginx has for configuration.

I'm not 100% with both, but I guess you have nginx be installed in some
dedicated pillar/playbook and you can have your application pillar/playbook
include templated configuration files to be inserted into /etc/nginx/conf.d
and notify the service to be reloaded somehow.

~~~
buro9
That much I know.

But when it's clearly a scenario that everyone using Nginx will be writing
these templates, surely it's better to have a well maintained master copy of
them.

The complexity usually comes in having multiple projects wanting to modify the
template(s) to wire themselves up.

A good sign for config tools is a feature rich and well maintained
recipe/playbook (whatever you want to call it) that is able to do the non-
trivial things (most deploy scripts for nginx don't seem to deal with SSL
particularly elegantly with all of the options involved).

Puppet does well at this, but I dislike the heavy dependencies that some of
the modules have. For example if you just wanted to install nginx you're going
to end up here: [https://github.com/jfryman/puppet-
nginx](https://github.com/jfryman/puppet-nginx) and will discover that you
have dependencies [https://github.com/jfryman/puppet-
nginx/blob/master/Modulefi...](https://github.com/jfryman/puppet-
nginx/blob/master/Modulefile) and will also need to install:
[https://github.com/puppetlabs/puppetlabs-
concat](https://github.com/puppetlabs/puppetlabs-concat)
[https://github.com/puppetlabs/puppetlabs-
apt](https://github.com/puppetlabs/puppetlabs-apt) and
[https://github.com/puppetlabs/puppetlabs-
stdlib](https://github.com/puppetlabs/puppetlabs-stdlib) . One of which has
their build failing.

What I look for in a config tool is such good defaults for handling these
complex (but commonplace) scenarios, that the recipes/modules/playbooks are
mature, dependency-free and well-maintained.

I guess I'm spoiled by programming in Go, I've got used to the idea that the
language includes a stdlib comprehensive enough that 90% of what you need
(even with those complex things like "give me a web server") is all built in.

That's the problem I'm trying to solve whenever I consider abandoning
Puppet... dependency hell.

But I also remember the pains when I first used Puppet: cross-cutting concerns
and complex configurations.

------
uggedal
As someone who used Puppet for some years, went to Salt[1], then Ansible[2],
I've setteled on POSIX sh[3],

1:
[http://git.uggedal.com/historic/states/](http://git.uggedal.com/historic/states/)

2:
[http://git.uggedal.com/historic/playbooks/](http://git.uggedal.com/historic/playbooks/)

3: [http://git.uggedal.com/conf](http://git.uggedal.com/conf)

~~~
stevekemp
I moved to a perl-based solution because that's a bit neater than shell:

[http://steve.org.uk/Software/slaughter/](http://steve.org.uk/Software/slaughter/)

I find it works well, each node pulls configuration from github, an rsync
share, or similar, and executes locally. So there's no master in the
traditional sense.

------
e12e
I've always been a bit wary of salt after:

[https://github.com/saltstack/salt/issues/2239](https://github.com/saltstack/salt/issues/2239)

Perhaps unfairly so... yet, I'm not entirely put at ease by:

[https://github.com/saltstack/salt/issues/5913](https://github.com/saltstack/salt/issues/5913)

Did salt ever move to a secure transport?

Then there's the (linked above, inline) issue with RSA exponent.

~~~
carlivar
Salt's REAT protocol uses the CurveCP crypto library, so yes, this is being
addressed.

~~~
e12e
So, _is being_ addressed not _has been_ addressed? Is REAT the future of Salt?
The most relevant I could find wasn't very clear:

[https://groups.google.com/forum/#!topic/salt-
users/nh8MqRiHV...](https://groups.google.com/forum/#!topic/salt-
users/nh8MqRiHVt4)

As far as I can tell RAET is still optional/Beta?:

[http://docs.saltstack.com/en/latest/topics/releases/2014.7.0...](http://docs.saltstack.com/en/latest/topics/releases/2014.7.0.html)

I tried finding out if CVEs had been assigned to the AES/RSA issues, but as
far as I can tell there weren't any CVEs assigned:

[http://www.cvedetails.com/vulnerability-
list/vendor_id-12943...](http://www.cvedetails.com/vulnerability-
list/vendor_id-12943/product_id-26420/Saltstack-Salt.html)

Mail suggesting CVE for RSA exponent: [http://www.openwall.com/lists/oss-
security/2013/07/01/1](http://www.openwall.com/lists/oss-
security/2013/07/01/1)

But the CVE is only reserved, not assigned?: [http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2013-2228](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2013-2228)

With the history of some very serious issues with the salt crypto, I'm a
little concerned that there doesn't seem to exist any good documentation on
the past and current state of the protocol security from the salt project?

As I said up-thread -- perhaps I'm not being fair, perhaps I'm just not aware
of where to look -- but I've yet to see anything that puts me entirely at
ease: have new members been added to the team? Has there been a successful
audit? Did the attacks turn out to not be practical?

While I might not have the same confidence in paramiko as I do in openssh --
at least it works with a well-tested protocol -- and more importantly -- with
a rather well-known protocol -- it's easier to evaluate. If someone can get
root access via ssh that _is_ bad. If the risk is limited to someone stealing
a private key, then that is at least something to plan around (and make
decisions around).

~~~
carlivar
Yeah, good questions for sure. I'd suggest asking on the SaltStack IRC channel
which is very active and helpful.

[http://www.saltstack.com/community/](http://www.saltstack.com/community/)

------
carlivar
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.

------
shiven
Just wanted to say I _love_ ansible!!! After the nightmare that was
Puppet/Chef, ansible has been just what the doc ordered. I keep all my
playbooks under version control (git) and deploy via ansible-playbook. KISS
philosophy; it has worked out better than _anything_ we used in the past.

------
mrmondo
IMO, Chef > Puppet > Ansible I wouldn't go near salt

~~~
dkarapetyan
Salt is also ok I think. I don't quite understand custom DSLs though for
configuration management. Giving users a library of idempotent code components
like chef does I think is way better than a custom language that is almost but
not quite or maybe turing complete. At some point you are going to want to
iterate and loop over stuff and if there is anything that ant has taught us is
that imperative things are better handled with imperative language constructs.
Trying to shoehorn everything into a declarative format is the wrong approach.

~~~
malraux
When that happens for me in Ansible I just drop into Python and write a custom
module. They're pretty straightforward.

~~~
dkarapetyan
The benefit with Chef is that it is always Ruby. There is no dropping in/out
of anything other than Ruby. As a Ruby programmer I quite like that. It
doesn't fight the language it is embedded in and uses all the language idioms
to great effect.

------
wernerb
> No masters. For Ansible this meant using ansible-playbook locally, and for
> Salt this meant using salt-call locally. Using a master for configuration
> management adds an unnecessary point of failure and sacrifices performance.

There are two models for delivering state to your infrastructure nodes.
Pulling and Pushing configuration. Ansible Pushes code from the controller to
your nodes, while salt, puppet and chef all pull state from a master
somewhere.

Like twic says, Ansible does not have a master. The original author says no
masters means faster performance. What he means is that pulling configuration
from a remote checkout equals faster performance, which is true because it can
be loadbalanced etc.

A chef/puppet master can have features such as search and service discovery
that should be a large red flag for SPOF problems.

~~~
twic
But Ansible doesn't have masters! It has a machine where you run Ansible. But
that can be any machine, as long as it has Ansible installed, the Ansible code
checked out, and an authorised SSH key. If your usual machine goes down, just
check out the code and run from a different machine. The idea that you need to
use local playbooks to use Ansible masterlessly just seems mistaken to me.

Moreover, any scheme which involves running local configuration (whether in
Ansible, Chef, or Puppet) involves either pushing configuration updates to
machines, or having the machines poll for configuration updates, in which case
it's no different to running remote configuration or having a master,
respectively.

I don't get the point about open ports. Are you running machines without SSH?
If you are, well done. But if, like most people, you're not, then you already
have all the port you need open.

~~~
wernerb
I haven't mentioned an Ansible Master? I referred to the user running ansible
as the controller.

Running local configuration and checking out local state can indeed be very
different from having a master. Like I said, master features often include
features such as search and service discovery. Checking out state from version
control does not have those features therefore the user implements those
features on his own with stateless cookbooks/pillars/modules/whatever. The
remote checkout is not a SPOF and a master is.

You are right in regard to the open ports, it is uncommon, though I have seen
it with workstations. I edited the post!

------
timmahoney
I'm currently working on a whole bunch of Ansible stuff, and I'm loving it. I
definitely agree with the author that the docs for beginners are excellent. No
experience with Salt as of yet, but I'll probably spin up a VM and screw
around with it at some point.

------
imsofuture
We're in the process of switching from Puppet to SaltStack. It's a change
measured in light-years. We didn't evaluate Ansible, so I can't speak to it --
but we are extremely happy with Salt's speed, flexibility + extensibility.

------
tootie
I feel like the entire configruation management movement has passed me by. I
still don't understand what value there is in chef/puppet/salt/ansible/docker
vs bash or even Perl for that matter. Someone care to set me straight?

~~~
GregorStocks
When you're managing more than a handful of servers, you very quickly start
wanting to be able to run the same command on multiple machines - "upgrade all
my API boxes to the not-vulnerable nginx", for instance, or "push this binary
out to all my database servers". These sorts of services make that
straightforward, and generally provide a large library of prewritten modules
to do moderately-complicated things without having to write a lot of
boilerplate or read somebody else's Bash scripts or Perl.

~~~
tootie
Well, I've done that just using remote shell commands. And I'd have an easier
time reading someone else's bash than I would their ansible whatevers. Is it
actually more concise?

~~~
eropple
When written correctly, it's idempotent. I've done a lot of server management
with bash and it's _a lot easier_ to achieve idempotency with something like
Chef.

------
jasonkolb
Ansible seems to have more traction:
[https://www.google.com/trends/explore#q=ansible%2C%20saltsta...](https://www.google.com/trends/explore#q=ansible%2C%20saltstack&cmpt=q)

~~~
dba7dba
Depends on how you view it.

According to the chart Ansible has been around since 2005? Salt is barely 2
years old? Look at the uptick of the last few months and SaltStack seems ever
slightly steeper than Ansible.

I am SaltStack guy, albeit a newbie. Barely got done installing (much much
easier than Puppet) and trying out few commands. I was hooked on SaltStack
when I was able to run following command once and get result from multiple
machines near simultaneously.

> salt "*" cmd.run "df -h'

I get result from all machines near simultaneously.

Above command is same as you logging into each machine (say hundreds or
thousands) and running 'df -h' to see status of your storage space. You could
write/test/deploy a shell script and push it out to all those machines. Or set
up some monitoring system. Or install SaltStack across your network (very
simple to do) and run above command once on your SaltStack server and get
immediate feedback.

I tried working with Puppet long time ago. The idea of having 20 minute window
for pushing out changes never seemed attractive to me.

~~~
Keats
First commit for Ansible in 2012
([https://github.com/ansible/ansible/commits/devel?page=329](https://github.com/ansible/ansible/commits/devel?page=329)).

I guess the previous searches are for the scifi tech devices

------
ashayh
No matter what fancy tools you use, all configuration on *nix machines happens
via files, and files in execution (called processes).

Given that, _all_ current configuration tools are overly complicated.

------
jv22222
Salt all the way. We moved digedu's highly distributed infrastructure from
puppet to salt and couldn't be happier with salt-cloud, salt-master, salt
states, pillar and jinja.

------
alexnewman
Very interesting. At least they aren't cfengine.

------
Kiro
May I ask why people think Puppet sucks?

~~~
twic
Crazy slow, linguistically poor, parser breaks in every release, really hard
to test locally.

~~~
Karunamon
I notice none of these problems on a 3.2 deployment with about 500 nodes.

I find that Ansible is roughly identical doing the same things on the same
machines timewise, not going to get into the subjective argument about the
language, the parser syntax is backwards compatible between major releases
(and they go well out of their way to warn you what you'll need to change
before something actually does break), and I don't see how it's any harder to
test locally than any other config management tool.

------
zwischenzug
I posted this on the site, thought some might be interested here (disclaimer:
I'm the creator of ShutIt):

We had similar requirements in our company and ended up building our own tool
for building containers in docker and shipping those. So far it's working out
really well, particularly in the "ease of learning" department.

[http://ianmiell.github.io/shutit/](http://ianmiell.github.io/shutit/).

[https://github.com/ianmiell/shutit](https://github.com/ianmiell/shutit)
[https://github.com/ianmiell/shutit/blob/master/README.md](https://github.com/ianmiell/shutit/blob/master/README.md)

[http://shutit.tk](http://shutit.tk)

To take each of your requirements in turn wrt ShutIt:

    
    
        - No masters. 
    

ShutIt builds containers for shipping, so there is no concept of a master.

    
    
        - Code should be as simple as possible.
    

What could be simpler than "pure bash", wrapped in a transparent and simple
python framework? eg here's the mysql module:

[https://github.com/ianmiell/shutit/blob/master/library/mysql...](https://github.com/ianmiell/shutit/blob/master/library/mysql/mysql.py)

    
    
        - No optimizations that would make the code read in an illogical order.
    

ShutIt is "pure ordered". Each module has an ordering and code is strictly
sequential. It even outputs the commands into a "black box" recorder on the
container which can then be used to port to other CM tools if desired.

    
    
        - Code must be split into two parts: base and service-specific, where each would reside in separate repositories. 
    

[https://github.com/ianmiell/shutit/tree/master/library](https://github.com/ianmiell/shutit/tree/master/library)

These are shared infra, while custom modules can be cut and kept private.

You can also build "meta-modules" which simply require other modules and do
nothing else. These then form the base layer of our dev builds.

    
    
        - The code must work for multiple environments (development, staging, production).
    

ShutIt's highly configurable, so you can code whatever you want wrt different
environments.

    
    
        - The code should read and run in sequential order.
    

ShutIt demands sequential ordering.

Any questions, please mail me: ian.miell@gmail.com

------
twovi
We chose SaltStack. Have not looked back once.

------
deathanatos
Please note that I have only had experience with Salt and fabric.

Salt falls short of what you want in the corner cases:

\- We've found it's darn hard to upgrade. (To be clear, we'd like to upgrade
by transitioning the master to a new VM; for one, this means things are clean
(we can provision our salt-master through a fabric script), but it also allows
us to change the amount of memory available.) The minions, when disconnected,
do not reconnect to the hostname in their config: instead, they endlessly
reconnect to the IP that the DNS resolved to when they were started. You can't
simply change a DNS record and have the minions move. Please note that we're a
bit behind in releases (we're using 0.17.2, IIRC) because of the difficulty of
upgrading.

\- YAML was a terrible choice for "state" files, in my opinion. State files
contain lists of commands to execute on a remote host being configured: trying
to specify args to functions in YAML is awkward.

\- I'm of the opinion that the master-minion relationship is backwards. I'd be
much more interested in something that connected to the minion. In particular,
this would help with upgrading (the minion is controlled by two masters for a
short period).

\- The command line utilities are prone to user error: they return success
during failure, they return no output and success because your states took too
long to run, and it got bored. You can look up the job ID, but it's painful.

\- The errors are utterly useless. In particular, Jinja rendering errors tend
to reference incorrect locations in files, returning nonsense such as use of
an undefined variable on a blank line.

\- The output is useless too: you get a (very) verbose listing of everything
that succeeded or failed. Telling if anything failed is the trick: it's buried
in all the successes. (Terminal find is my friend here, but still, you have to
be careful to watch out for boundaries between runs and not read an old run's
output.) As discussed, the return code won't help you here.

\- AFAICT, you need to be a particular user, and there is really no ACLs to
speak of. All of our Salt stuff currently runs as a single user. People
inevitably step on each others' toes.

\- Non-responsive nodes are not mentioned in the output: they're the same as
if they didn't exist! This results in some really wacky stuff happening. If
you have variables that are lists of machines, the machine simply won't be in
the list. This means if you need N of some type of machine, that list will be
empty. (This often then triggers the aforementioned unreadable jinja error
output, if you assume the list to be non-empty.)

\- There is little capability for actual processing on the master itself.
Sometimes, you need to coordinate the actions of several nodes together, such
as generating keys for each node, and then distributing all keys to all nodes.

------
foton1981
Guys just have too much time...

------
andyl
I've had experience with Chef, Puppet and Ansible. Ansible is the least
complex, and we're using it daily. Re: Ansible community dynamic - I've gotten
unfriendly feedback a few times and agree with the negative reputation. Aside
from community, Ansible is a big step up, and I suspect Salt would be as well.

~~~
mpdehaan2
I'm sorry you thought we were unfriendly.

Don't read too much into responses if we don't go out of our way to say "Hi
yall", but we do try to say thank you a giant ton.

We're pushing an IRC channel of about 800 people now, and I think we're mostly
just trying to be concise in the waves of giant teaming hordes of Ansible
users :)

If you don't let that get under your skin, you'll be fine! We're happy
everyone is here, usually. Though we'll also share when the design decision of
something is that way for a reason.

As it is said, "go not to the elves for council, for they shall say both no
and yes" :)

Mostly we're just trying to get you on your feet as quickly as possible.

Try the tool, by all means, if we're ever short, it's because we're so
incredibly busy, and we're thankful for every user we have.

------
rdtsc
I usually look at Salt as more advanced and perhaps a replacement of Puppet
and other such declarative configuration system. I see Ansible as more of a
replacement of a bunch of SSH + scripts.

~~~
mpdehaan2
Basically with Ansible all the declarative stuff in ansible is there and
you'll be able to do all those things you want to do from Puppet and Chef.

However you can also do the app deployment stuff that you would typically do
with Fabric or Capistrano.

The point really is to avoid using both, but in many ways, you could start
with one, or only use one.

There are definitely folks in various stages of development where they start
with one side of the coin and eventually migrate both sides.

But yeah, app deployment is definitely a focus, and I think for most people is
a bigger driver than the basic config management stuff.

But is the declarative stuff there? 100%.

