3 ms·

I wish some other question was asked more: "for configuration management, why Ansible with its atrocious YAML-encoded programming language over CFEngine or Pupp

by dozzie 10y ago

I wish some other question was asked more: "for configuration management, why Ansible with its atrocious YAML-encoded programming language over CFEngine or Puppet?"

throwanem 10y ago
I agree that YAML's a mess, but not requiring a client-side agent is a pretty big win in my experience, and to be honest none of the configuration management systems I've used has had a particularly comfortable specification language.
- zwischenzug 10y ago
  I've learned the hard way that CM is a Hard Problem. Any solution is going to be a trade-off, which is why there is space for multiple solutions.
- dozzie 10y ago
  Oh, but Ansible does require a client-side agent. It just happens that the agent is the same one as you use for interactive purposes, which is another big no-go in the long run (when you let your servers' users configure SSH server to some extent, and then you need to make sure they don't cut out your configuration management tool). Also, configuration management tool should be, apart from downloading configuration from somewhere, independent from any external server/service.
  - throwanem 10y ago
    See your own sibling comment from the ShutIt dev.
    - dozzie 10y ago
      The one that is cutely general and thus at the same time completely agreeable by anybody and totally unactionable? Sure, I've seen it.
      - zwischenzug 10y ago
        Client-side agent is great for some orgs (esp those that need control), but I wanted something that would be more general-purpose (hence using (p)expect).
  - collyw 10y ago
    Yes, but is pretty standard. Could you even use a virtual machine without ssh (or an equivalent)?
    - 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.

by dozzie 10y ago

I wish some other question was asked more: "for configuration management, why Ansible with its atrocious YAML-encoded programming language over CFEngine or Puppet?"

throwanem 10y ago

I agree that YAML's a mess, but not requiring a client-side agent is a pretty big win in my experience, and to be honest none of the configuration management systems I've used has had a particularly comfortable specification language.

zwischenzug 10y ago
I've learned the hard way that CM is a Hard Problem. Any solution is going to be a trade-off, which is why there is space for multiple solutions.
dozzie 10y ago
Oh, but Ansible does require a client-side agent. It just happens that the agent is the same one as you use for interactive purposes, which is another big no-go in the long run (when you let your servers' users configure SSH server to some extent, and then you need to make sure they don't cut out your configuration management tool). Also, configuration management tool should be, apart from downloading configuration from somewhere, independent from any external server/service.
- throwanem 10y ago
  See your own sibling comment from the ShutIt dev.
  - dozzie 10y ago
    The one that is cutely general and thus at the same time completely agreeable by anybody and totally unactionable? Sure, I've seen it.
    - zwischenzug 10y ago
      Client-side agent is great for some orgs (esp those that need control), but I wanted something that would be more general-purpose (hence using (p)expect).
- collyw 10y ago
  Yes, but is pretty standard. Could you even use a virtual machine without ssh (or an equivalent)?
  - 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.