2 ms·

As a (somewhat) seasoned sysadmin, I tell you that mixing responsibilities of services is a Bad Idea[tm]. You wouldn't put disk access into your HTTP header han

by dozzie 10y ago

As a (somewhat) seasoned sysadmin, I tell you that mixing responsibilities of services is a Bad Idea[tm]. You wouldn't put disk access into your HTTP header handling code, would you? So why do you think overloading an interactive shell with configuration management is a good idea? It doesn't even work well, considering that you need to manage SSH keys, which quickly gets ugly when the number of hosts grows, and then there's the need to re-send configuration for each host that happened to be down or otherwise unreachable at the time of issuing it the first time. You need a) interactive shell, b) configuration management tool (which works in scheduled batch mode and in "pull" style, not "push" as in Ansible), and c) system for running ad-hoc commands synchronously (this one is "push" style). Yes, all three. Yes, separate, not a weird mix of them. Been there, done that.

throwanem 10y ago
Nobody's saying that Puppet or CFEngine isn't the best solution for a lot of cases, only that there are also cases where Ansible, or something like it, is a better choice. You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. Have you had a bad experience with it? If so, I'd like to hear about it, in order to better inform my own analysis of the tool.
- dozzie 10y ago
  > You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. No, not really. Not on the high-level idea(s). Heck, I've written myself (or at least deployed already-written) tools for what Ansible tries to do: configuration management, synchronous mass running an ad-hoc command on a set of machines, and running a specific, parametrized procedure on a single host. I recognize all these scenarios are important and I want to have tools for each of those, but let the tools do these jobs robustly. What bothers me is design decisions and architecture of Ansible (and other tools sharing them). The decisions seem sound from far away, but they start leaking once you look closely. Good general tool would be robust for pretty much all the use cases; Ansible is brittle (breaks when you misconfigure sshd_config a little; breaks when you accidentally overwrite SSH keys; can't work if you don't have account with working shell and $HOME; breaks apart when some of the hosts are down; and so on). Ansible apparently started as a script that automated somebody's workflow (which is a good thing) -- and stayed that way, but now is marketed as a general tool (which is not, but resembles it closely enough to trick many its users into thinking it is). It all boils down to Ansible still being a quick hack for somebody's specific workflow and me hating buzz around half-assed tools. > Have you had a bad experience with it? If so, I'd like to hear about it, in order to better inform my own analysis of the tool. I have so many objections against Ansible (some I mentioned above) that it actually makes more sense to write a separate article about it, but this will take time.
  - zwischenzug 10y ago
    > Ansible apparently started as a script that automated somebody's workflow (which is a good thing) -- and stayed that way, but now is marketed as a general tool (which is not, but resembles it closely enough to trick many its users into thinking it is). I think that's a key critique of many of these things. They start off solving one problem, then eventually become 'enterprise', and the design trade-offs get exposed. This is what I was alluding to above with my trade-offs comment.
    - dozzie 10y ago
      Well, CFEngine (especially 3.x, a third rewrite of the same basic idea) does not show these trade-offs. It was designed from the ground up as a general tool based on previous experiences with wide deployments, it (its codebase) did not start as a script for solving some specific problem in some specific workflow. Puppet has similar history, I believe, as a tool that was written to replace cfengine (2.x) without its shortcomings.

by dozzie 10y ago

throwanem 10y ago

Nobody's saying that Puppet or CFEngine isn't the best solution for a lot of cases, only that there are also cases where Ansible, or something like it, is a better choice. You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. Have you had a bad experience with it? If so, I'd like to hear about it, in order to better inform my own analysis of the tool.

dozzie 10y ago
> You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. No, not really. Not on the high-level idea(s). Heck, I've written myself (or at least deployed already-written) tools for what Ansible tries to do: configuration management, synchronous mass running an ad-hoc command on a set of machines, and running a specific, parametrized procedure on a single host. I recognize all these scenarios are important and I want to have tools for each of those, but let the tools do these jobs robustly. What bothers me is design decisions and architecture of Ansible (and other tools sharing them). The decisions seem sound from far away, but they start leaking once you look closely. Good general tool would be robust for pretty much all the use cases; Ansible is brittle (breaks when you misconfigure sshd_config a little; breaks when you accidentally overwrite SSH keys; can't work if you don't have account with working shell and $HOME; breaks apart when some of the hosts are down; and so on). Ansible apparently started as a script that automated somebody's workflow (which is a good thing) -- and stayed that way, but now is marketed as a general tool (which is not, but resembles it closely enough to trick many its users into thinking it is). It all boils down to Ansible still being a quick hack for somebody's specific workflow and me hating buzz around half-assed tools. > Have you had a bad experience with it? If so, I'd like to hear about it, in order to better inform my own analysis of the tool. I have so many objections against Ansible (some I mentioned above) that it actually makes more sense to write a separate article about it, but this will take time.
- zwischenzug 10y ago
  > Ansible apparently started as a script that automated somebody's workflow (which is a good thing) -- and stayed that way, but now is marketed as a general tool (which is not, but resembles it closely enough to trick many its users into thinking it is). I think that's a key critique of many of these things. They start off solving one problem, then eventually become 'enterprise', and the design trade-offs get exposed. This is what I was alluding to above with my trade-offs comment.
  - dozzie 10y ago
    Well, CFEngine (especially 3.x, a third rewrite of the same basic idea) does not show these trade-offs. It was designed from the ground up as a general tool based on previous experiences with wide deployments, it (its codebase) did not start as a script for solving some specific problem in some specific workflow. Puppet has similar history, I believe, as a tool that was written to replace cfengine (2.x) without its shortcomings.