5 ms·

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 require

by 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]
    - ymse 10y ago
      Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash. Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual: $ man puppet PUPPET(8) Puppet manual PUPPET(8) NAME puppet See ´puppet help´ for help on available puppet subcommands Obviously no-one will be using everything that Salt supports, so it would be nice if it was broken into sub-sections. But I much prefer having all documentation available in a manual to looping through every module and run "rdoc" as in the Puppet case. Any sufficiently popular configuration management tool will have equally long documentation. There are a couple of simpler options available: http://www.nico.schottelius.org/software/cdist/ http://www.nico.schottelius.org/software/cdist/ https://github.com/brandonhilkert/fucking_shell_scripts https://github.com/brandonhilkert/fucking_shell_scripts
      - bpchaps 10y ago
        "Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better. When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module execution. I understand why they do it this way, but if they documented it in plain sight, then maybe my desk wouldn't have a forehead shaped dent in it. Similar goes for the other tools. The only thing I can think of that prevents companies from releasing proper documentation is because of their expensive support contracts. There's a lot of incentive to make a standard incredibly difficult. I just want accessible tools :( edit: fss looks pretty neat! Kinda rpm-y, but it fits a nice middle ground.
        ymse 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.

by bcoca 10y ago

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]
  - ymse 10y ago
    Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash. Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual: $ man puppet PUPPET(8) Puppet manual PUPPET(8) NAME puppet See ´puppet help´ for help on available puppet subcommands Obviously no-one will be using everything that Salt supports, so it would be nice if it was broken into sub-sections. But I much prefer having all documentation available in a manual to looping through every module and run "rdoc" as in the Puppet case. Any sufficiently popular configuration management tool will have equally long documentation. There are a couple of simpler options available: http://www.nico.schottelius.org/software/cdist/ http://www.nico.schottelius.org/software/cdist/ https://github.com/brandonhilkert/fucking_shell_scripts https://github.com/brandonhilkert/fucking_shell_scripts
    - bpchaps 10y ago
      "Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better. When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module execution. I understand why they do it this way, but if they documented it in plain sight, then maybe my desk wouldn't have a forehead shaped dent in it. Similar goes for the other tools. The only thing I can think of that prevents companies from releasing proper documentation is because of their expensive support contracts. There's a lot of incentive to make a standard incredibly difficult. I just want accessible tools :( edit: fss looks pretty neat! Kinda rpm-y, but it fits a nice middle ground.
      - ymse 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.