8 ms·

Sorry if this seems willfully ignorant, but what advantage does this provide over just using something like Ansible?

by usrme 6y ago

drcongo 6y ago
For me the answer is debuggability. Debugging Ansible can be incredibly painful at times.
- usrme 6y ago
  I guess I haven't used Ansible long enough to know such pain points. Would you elaborate with some examples?
  - peterwwillis 6y ago
    This is a bit like asking what the Marquis de Sade did that was so painful. I don't even know where to begin explaining how frustrating Ansible is. Over time they've compounded one bad design decision on top of another, while never adding any actually useful functionality to be able to troubleshoot or iterate on the many random failures. They also don't provide guidance on how "if you use feature X, features a, b, c, d, and e will not work correctly". Finding a working example of core functionality, like an AWS inventory plugin, requires you to dig through all of the code and scour the internet and experiment for a day before you have a simple working configuration. The more features you use, the more fragile and shitty it becomes, to the point that nobody wants to actually change any roles or playbooks because deployments might stop working and it'll take you two days to figure out how to make them work again in Ansible's bass-ackwards design. And of course, it's Python, so you have to teach all your users how to use virtualenvs, freeze deps, and run it with Docker, or you'll constantly hear "it didn't run correctly for me".
    - godtoldmetodoit 6y ago
      I've been neck deep in Ansible for the past couple of months, and boy, I am not a fan. Documentation is middling at best imo and it just feels hacked together.
      - pampa 6y ago
        It is easy to pick up and do easy tasks. Like installing a package on ubuntu and setup ufw. Then you throw in a few centos hosts and have to write if-else in yaml. Then u try to provision docker and end up with more if-else blocks to install the required python packages. Then you get to the part where you want to provision a database with presistent storage inside a docker container and just give up.
      - isbvhodnvemrwvn 6y ago
        The two things that came into my mind when I first used Ansible was "bash" and "hudson/jenkins". It seems like a tool which was written by an ops person (as in hacked together) for ops people (who don't mind stuff being hacked together), specifically for replacing manually distributed cryptic bash files. It's an improvement over that, for sure, but that's it.
    - lixtra 6y ago
      > run it with Docker Isn’t the point of Docker that not everyone has to know the virtual envs, etc?
      - peterwwillis 6y ago
        Yes, if you freeze deps you can just install to the system paths in a Docker container. But most people who I've distributed Dockerized ansible git repos to don't read the README and don't try to run it in Docker, so they flail around trying to get it running without a venv or anything, until I finally convince them to just use the container (they're not familiar with containers either so it's almost as much of a slog). I hate technology.
  - 1337shadow 6y ago
    For example, executing a long command: you will not see any output until the command exits.
    - isbvhodnvemrwvn 6y ago
      And it's a fundamental flaw in the architecture, it can't be easily fixed.
  - dec0dedab0de 6y ago
    Ansible error messages have gotten better, but there are still plenty of times where it will take a configuration error such as a missing module argument and report on it as a syntax error. And then when you get those errors you need to understand what the object is and now you're running the debug on a ton of variables, some of which you first need to set facts on, then others you don't know what are available. IMO the biggest problem with Ansible is that it feels like it was designed with a really good idea in mind, and then extended and modified by a bunch of different teams who had their own ideas. Which is fine if you've been paying attention, but explaining it all to someone new can be overwhelming.
    - deleted 6y ago
      [deleted]
dec0dedab0de 6y ago
At a glance it seems more comparable to fabric than Ansible. Ansible is not really about controlling computers, it's about declarative configuration. One major benefit over ansible is that you only need a posix shell on the remote side, instead of a compatible version of python and possibly some specific libraries. Which is a also a major downside if you want to manage systems that don't have a posix shell.
- Fizzadar 6y ago
  Very much this - pyinfra was heavily inspired by both Fabric & Ansible. Beyond POSIX, pyinfra now supports winrm (experimental) - https://pyinfra.readthedocs.io/en/v0.14.5/connectors.html#winrm https://pyinfra.readthedocs.io/en/v0.14.5/connectors.html#wi....
pydry 6y ago
ansible's declarative manifests got pretty complicated and even (potentially, not sure if it actually happened) achieved accidental turing completeness. if your DSL gets to that point sometimes it's better to rewrite as a library.
- 1337shadow 6y ago
  which pyinfra seems to achieve perfectly
BiteCode_dev 6y ago
Fair question. Ansible is a great system, with a terrible DSL. YAML is not a programming language, and deployment is not a toy task. You need power. The result is that ansible has pushed a markup language to its limit, then pushed the templating engine used in it to its limit too. Then used a bunch of duck tape + conventions to glue everything and ended up with 10% of an unclean verbose unexpressive real programming language with ridiculous limited tooling, testability and had to document + support it. As with most DSL. For what? For the quest of having something "declarative", and that any language could read. Well you can have declarative API written in any language, and nobody except ansible ever read playbooks. In the end, it's just a big weight at the ankle. I never ever used it and though, "damn, what a pleasant tech choice, I'm happy they didn't directly expose the API through Python". It's the same reason I use "nox" and not "tox", or "doit" and not "make". DSL really seem like a great idea, but they fail most of the time. There is a reason only few of them - like SQL, CSS or regex patterns - became a success. 99% of the time, what you need is a good lib, with a well designed API. For the 0.9% of the time you do need multi-language communication, you may implement RPC. Then, only for the 0.01% case should you really consider a DSL. But we geek love to create DSL. They are fun to write! They are so elegant in tutorials! Is Pyinfra doing better? I don't know, but I'm sure to give it a try. I really, really want to leave ansible behind, but fabric 2 is not high level or declarative enough.
- eradman 6y ago
  Well said! This is largely the motivation for frameworks that give you only what you need to write your own automation: https://github.com/eradman/rset https://github.com/eradman/rset https://github.com/rollcat/judo https://github.com/rollcat/judo
sly010 6y ago
Ansible's pretend-declarative yaml doesn't add any value, while forcing you to use patterns that rarely match your use-case. It should have been a python library without all the yaml from the beginning. That said, pyinfra seems to be making the same mistakes (being a tool instead of a library, prescribing a folder structure, not letting me create my own abstractions), so you are right that it provides no advantage over Ansible.
- BiteCode_dev 6y ago
  While it would be nice to have the core and the framework dissociated, stating that it provide no advantage over Ansible seems overly broad. You can use python logic to compose your deployment scenario, use imports to reuse features, package modules the same way, etc. The whole ecosystem is also at your disposal, be it libraries, IDE support, linters, formatters, debuggers and so on. It doesn't need to reinvent the wheel, and you don't need to learn a new syntax. I would call that a win. Now, is pyinfra well designed enough to be practical in production, that's another matter that needs testing.
- 1337shadow 6y ago
  Well then maybe this is more for you yourlabs.io/oss/shlax (it's still in development, check the pipeline build job to see some outputs) But honestly pyinfra seems like the clean Ansible rewrite for people who like both devops and python programing, pyinfra looks like the next major version of Ansible.
  - BiteCode_dev 6y ago
    Thanks for sharing Shlax, I didn't know about it, and at first glance, I like the design choices: encapsulate task, pass the target object so you can mock it for testing, use await to delegate I/O...
    - 1337shadow 6y ago
      Shlax still has to prove it can do what it aims with the simple design it strives to keep.

Sorry if this seems willfully ignorant, but what advantage does this provide over just using something like Ansible?

by usrme 6y ago

Sorry if this seems willfully ignorant, but what advantage does this provide over just using something like Ansible?

drcongo 6y ago

For me the answer is debuggability. Debugging Ansible can be incredibly painful at times.

usrme 6y ago
I guess I haven't used Ansible long enough to know such pain points. Would you elaborate with some examples?
- peterwwillis 6y ago
  This is a bit like asking what the Marquis de Sade did that was so painful. I don't even know where to begin explaining how frustrating Ansible is. Over time they've compounded one bad design decision on top of another, while never adding any actually useful functionality to be able to troubleshoot or iterate on the many random failures. They also don't provide guidance on how "if you use feature X, features a, b, c, d, and e will not work correctly". Finding a working example of core functionality, like an AWS inventory plugin, requires you to dig through all of the code and scour the internet and experiment for a day before you have a simple working configuration. The more features you use, the more fragile and shitty it becomes, to the point that nobody wants to actually change any roles or playbooks because deployments might stop working and it'll take you two days to figure out how to make them work again in Ansible's bass-ackwards design. And of course, it's Python, so you have to teach all your users how to use virtualenvs, freeze deps, and run it with Docker, or you'll constantly hear "it didn't run correctly for me".
  - godtoldmetodoit 6y ago
    I've been neck deep in Ansible for the past couple of months, and boy, I am not a fan. Documentation is middling at best imo and it just feels hacked together.
    - pampa 6y ago
      It is easy to pick up and do easy tasks. Like installing a package on ubuntu and setup ufw. Then you throw in a few centos hosts and have to write if-else in yaml. Then u try to provision docker and end up with more if-else blocks to install the required python packages. Then you get to the part where you want to provision a database with presistent storage inside a docker container and just give up.
    - isbvhodnvemrwvn 6y ago
      The two things that came into my mind when I first used Ansible was "bash" and "hudson/jenkins". It seems like a tool which was written by an ops person (as in hacked together) for ops people (who don't mind stuff being hacked together), specifically for replacing manually distributed cryptic bash files. It's an improvement over that, for sure, but that's it.
  - lixtra 6y ago
    > run it with Docker Isn’t the point of Docker that not everyone has to know the virtual envs, etc?
    - peterwwillis 6y ago
      Yes, if you freeze deps you can just install to the system paths in a Docker container. But most people who I've distributed Dockerized ansible git repos to don't read the README and don't try to run it in Docker, so they flail around trying to get it running without a venv or anything, until I finally convince them to just use the container (they're not familiar with containers either so it's almost as much of a slog). I hate technology.
- 1337shadow 6y ago
  For example, executing a long command: you will not see any output until the command exits.
  - isbvhodnvemrwvn 6y ago
    And it's a fundamental flaw in the architecture, it can't be easily fixed.
- dec0dedab0de 6y ago
  Ansible error messages have gotten better, but there are still plenty of times where it will take a configuration error such as a missing module argument and report on it as a syntax error. And then when you get those errors you need to understand what the object is and now you're running the debug on a ton of variables, some of which you first need to set facts on, then others you don't know what are available. IMO the biggest problem with Ansible is that it feels like it was designed with a really good idea in mind, and then extended and modified by a bunch of different teams who had their own ideas. Which is fine if you've been paying attention, but explaining it all to someone new can be overwhelming.
  - deleted 6y ago
    [deleted]

dec0dedab0de 6y ago

At a glance it seems more comparable to fabric than Ansible. Ansible is not really about controlling computers, it's about declarative configuration. One major benefit over ansible is that you only need a posix shell on the remote side, instead of a compatible version of python and possibly some specific libraries. Which is a also a major downside if you want to manage systems that don't have a posix shell.

Fizzadar 6y ago
Very much this - pyinfra was heavily inspired by both Fabric & Ansible. Beyond POSIX, pyinfra now supports winrm (experimental) - https://pyinfra.readthedocs.io/en/v0.14.5/connectors.html#winrm https://pyinfra.readthedocs.io/en/v0.14.5/connectors.html#wi....

pydry 6y ago

ansible's declarative manifests got pretty complicated and even (potentially, not sure if it actually happened) achieved accidental turing completeness. if your DSL gets to that point sometimes it's better to rewrite as a library.

1337shadow 6y ago
which pyinfra seems to achieve perfectly

BiteCode_dev 6y ago

Fair question. Ansible is a great system, with a terrible DSL. YAML is not a programming language, and deployment is not a toy task. You need power. The result is that ansible has pushed a markup language to its limit, then pushed the templating engine used in it to its limit too. Then used a bunch of duck tape + conventions to glue everything and ended up with 10% of an unclean verbose unexpressive real programming language with ridiculous limited tooling, testability and had to document + support it. As with most DSL. For what? For the quest of having something "declarative", and that any language could read. Well you can have declarative API written in any language, and nobody except ansible ever read playbooks. In the end, it's just a big weight at the ankle. I never ever used it and though, "damn, what a pleasant tech choice, I'm happy they didn't directly expose the API through Python". It's the same reason I use "nox" and not "tox", or "doit" and not "make". DSL really seem like a great idea, but they fail most of the time. There is a reason only few of them - like SQL, CSS or regex patterns - became a success. 99% of the time, what you need is a good lib, with a well designed API. For the 0.9% of the time you do need multi-language communication, you may implement RPC. Then, only for the 0.01% case should you really consider a DSL. But we geek love to create DSL. They are fun to write! They are so elegant in tutorials! Is Pyinfra doing better? I don't know, but I'm sure to give it a try. I really, really want to leave ansible behind, but fabric 2 is not high level or declarative enough.

eradman 6y ago
Well said! This is largely the motivation for frameworks that give you only what you need to write your own automation: https://github.com/eradman/rset https://github.com/eradman/rset https://github.com/rollcat/judo https://github.com/rollcat/judo

sly010 6y ago

Ansible's pretend-declarative yaml doesn't add any value, while forcing you to use patterns that rarely match your use-case. It should have been a python library without all the yaml from the beginning. That said, pyinfra seems to be making the same mistakes (being a tool instead of a library, prescribing a folder structure, not letting me create my own abstractions), so you are right that it provides no advantage over Ansible.

BiteCode_dev 6y ago
While it would be nice to have the core and the framework dissociated, stating that it provide no advantage over Ansible seems overly broad. You can use python logic to compose your deployment scenario, use imports to reuse features, package modules the same way, etc. The whole ecosystem is also at your disposal, be it libraries, IDE support, linters, formatters, debuggers and so on. It doesn't need to reinvent the wheel, and you don't need to learn a new syntax. I would call that a win. Now, is pyinfra well designed enough to be practical in production, that's another matter that needs testing.
1337shadow 6y ago
Well then maybe this is more for you yourlabs.io/oss/shlax (it's still in development, check the pipeline build job to see some outputs) But honestly pyinfra seems like the clean Ansible rewrite for people who like both devops and python programing, pyinfra looks like the next major version of Ansible.
- BiteCode_dev 6y ago
  Thanks for sharing Shlax, I didn't know about it, and at first glance, I like the design choices: encapsulate task, pass the target object so you can mock it for testing, use await to delegate I/O...
  - 1337shadow 6y ago
    Shlax still has to prove it can do what it aims with the simple design it strives to keep.