6 ms·

I have not been a big fan of Ansible due to some critical bugs (at least in 1.x) and the way how its community core committers are treating community requests l

by devy 10y ago

I have not been a big fan of Ansible due to some critical bugs (at least in 1.x) and the way how its community core committers are treating community requests like this. For one: Ansible 1.x cannot even print out the syntax error file and line number in the offending Playbook. [1] And their core committers ignored the issue and refuse to backport the basic debugging requirement after issue being opened 2 years. That itself, is a deal breaker for me. [1]: https://github.com/ansible/ansible/issues/5797 https://github.com/ansible/ansible/issues/5797 Edit: Downvoting me doesn't make this issue go away. What was requested is a simple basic debugging requirement - any mature syntax tree parsers should be able to do it.

therealmarv 10y ago
When it's that easy then implement it yourself and make a PR to Ansible ;)
- devy 10y ago
  Apparently it's NOT easy to implement according to Ansible dev above.
  - ryan_lane 10y ago
    It's also not that easy to get PRs accepted.
bcoca 10y ago
disclaimer: i'm an ansible dev. As the ticket shows, this was added in the 2.x release of Ansible, that is why the ticket was closed. Adding this info required a major revamp of the parser, which we did in 2.x, for this and many other reasons. This is not a simple change in 1.x and we decided not to backport it.
- bpchaps 10y ago
  Could you? Tons and tons of companies are forced into using outdated versions (for tons of reasons) where point release updates are still possible. I'm sure it's a lot of work, but a lot of your core and original users would appreciate it. Not implementing something as useful as that just has a "we got 'em, no need to do anything else for them" vibe.
  - devy 10y ago
    > Tons and tons of companies are forced into using outdated versions (for tons of reasons) where point release updates are still possible. Exactly my point! Ansible devs should own up to it for admitting their BAD design choice (I heard someone from here saying intentionally not use a parser but use YAML.) of not being able to get syntax error file name + line number! My story was that debugging ansible playbook with loads of nonsense cryptic error messages due to syntax errors that I have to spent hours to figure out what went wrong was a complete frustration. It was so bad that we eventually re-designed our infrastructure to cut out Ansible and never look back again. So much for Ansible 2.x that it doesn't even matter. Ansible lost its appeal in 1.x, and that's it. No more 2.x upgrades. Lesson learned here is that if a young software tools got adopted but early version caused so many frustrations that the authors don't care about back-porting bugfixes, all future version becomes irrelevant.
    - bpchaps 10y ago
      It's gotten so bad with these sorts of tools with their incredibly annoying design flaws that I've been debating creating my own using rpm and ssh on top of bash with some python. I get why it's important to have a lot of the features, but when the devops crowd thinks [0] is acceptable (or at the very least, doesn't scream about it), then it might be time for something new.. with [1] in mind. [0] $ man salt 2>/dev/null | wc -l 140905 [1] https://xkcd.com/927/ https://xkcd.com/927/
      - deleted 10y ago
        [deleted]
      - 10y ago
- technofiend 10y ago
  Although it's cool you guys fixed it - thank you for that - those of us sitting out in RedHat land may not see 2.1 sitting on EPEL for a very long time. So it's a legit request.
  - wyaeld 10y ago
    its in 2.0, which is available on RHEL
    - technofiend 10y ago
      Ah ok if it's in 2.0 then you're right! I thought it was exclusive to 2.1.
gerbilly 10y ago
>any mature syntax tree parsers should be able to do it. Well thats' just it, I don't think they use such a parser. I always thought that's why they use YAML as their input language, to avoid having to write a parser, I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design. [1] https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 (Also known in my day as 'turdcap'.)
- threatofrain 10y ago
  I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actually YAML or anything else. Now people write large system deployment scripts in this weird YAML that I don't ever want to look at.
  - collyw 10y ago
    JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.
    - threatofrain 10y ago
      JSON is the example, not the prescription; JSON is just a widely used format for arbitrarily nested data. You can use Javascript objects (or Python dictionaries) if you want. Again, this example applies for the scenario if Ansible playbooks were only configurations. If it were only configurations, then fine, let's go with readable YAML. If Ansible were playbooks with only configurations, then even XML would be okay, because in the sum of all pros and cons, this would be a tiny factor. The pickiness of quotes and trailing commas is really whatever here. But instead Ansible playbooks use a "readable" YAML-ish language. The price is not right.
- 10y ago

by devy 10y ago

therealmarv 10y ago

When it's that easy then implement it yourself and make a PR to Ansible ;)

devy 10y ago
Apparently it's NOT easy to implement according to Ansible dev above.
- ryan_lane 10y ago
  It's also not that easy to get PRs accepted.

bcoca 10y ago

disclaimer: i'm an ansible dev. As the ticket shows, this was added in the 2.x release of Ansible, that is why the ticket was closed. Adding this info required a major revamp of the parser, which we did in 2.x, for this and many other reasons. This is not a simple change in 1.x and we decided not to backport it.

bpchaps 10y ago
Could you? Tons and tons of companies are forced into using outdated versions (for tons of reasons) where point release updates are still possible. I'm sure it's a lot of work, but a lot of your core and original users would appreciate it. Not implementing something as useful as that just has a "we got 'em, no need to do anything else for them" vibe.
- devy 10y ago
  > Tons and tons of companies are forced into using outdated versions (for tons of reasons) where point release updates are still possible. Exactly my point! Ansible devs should own up to it for admitting their BAD design choice (I heard someone from here saying intentionally not use a parser but use YAML.) of not being able to get syntax error file name + line number! My story was that debugging ansible playbook with loads of nonsense cryptic error messages due to syntax errors that I have to spent hours to figure out what went wrong was a complete frustration. It was so bad that we eventually re-designed our infrastructure to cut out Ansible and never look back again. So much for Ansible 2.x that it doesn't even matter. Ansible lost its appeal in 1.x, and that's it. No more 2.x upgrades. Lesson learned here is that if a young software tools got adopted but early version caused so many frustrations that the authors don't care about back-porting bugfixes, all future version becomes irrelevant.
  - bpchaps 10y ago
    It's gotten so bad with these sorts of tools with their incredibly annoying design flaws that I've been debating creating my own using rpm and ssh on top of bash with some python. I get why it's important to have a lot of the features, but when the devops crowd thinks [0] is acceptable (or at the very least, doesn't scream about it), then it might be time for something new.. with [1] in mind. [0] $ man salt 2>/dev/null | wc -l 140905 [1] https://xkcd.com/927/ https://xkcd.com/927/
    - deleted 10y ago
      [deleted]
    - 10y ago
technofiend 10y ago
Although it's cool you guys fixed it - thank you for that - those of us sitting out in RedHat land may not see 2.1 sitting on EPEL for a very long time. So it's a legit request.
- wyaeld 10y ago
  its in 2.0, which is available on RHEL
  - technofiend 10y ago
    Ah ok if it's in 2.0 then you're right! I thought it was exclusive to 2.1.

gerbilly 10y ago

>any mature syntax tree parsers should be able to do it. Well thats' just it, I don't think they use such a parser. I always thought that's why they use YAML as their input language, to avoid having to write a parser, I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design. [1] https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 (Also known in my day as 'turdcap'.)

threatofrain 10y ago
I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actually YAML or anything else. Now people write large system deployment scripts in this weird YAML that I don't ever want to look at.
- collyw 10y ago
  JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.
  - threatofrain 10y ago
    JSON is the example, not the prescription; JSON is just a widely used format for arbitrarily nested data. You can use Javascript objects (or Python dictionaries) if you want. Again, this example applies for the scenario if Ansible playbooks were only configurations. If it were only configurations, then fine, let's go with readable YAML. If Ansible were playbooks with only configurations, then even XML would be okay, because in the sum of all pros and cons, this would be a tiny factor. The pickiness of quotes and trailing commas is really whatever here. But instead Ansible playbooks use a "readable" YAML-ish language. The price is not right.
10y ago