Ansible 2.1 Released, with Network Automation, Containers

Post by devy » Thu, May 26, 2016, 8:33 PM UTC

bpchaps wrote: post #62

bcoca wrote: post #38

Earlier quoted context omitted.

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.

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.

Post by gerbilly » Thu, May 26, 2016, 8:38 PM UTC

GauntletWizard wrote: post #71

gerbilly wrote: post #53

Earlier quoted context omitted.

I think we have to distinguish two things going on in Ansible files. 1) It's declarative. So if you are looking for a procedural language, you will be disappointed. It's also declarative for good reason IMHO. 2) It's still hacky. If the 'language' remained entirely declarative then the YAML syntax _might_ have been ok, but the language looks like a poor design stretched beyond it's limits. Some people don't like the…

Ansible has none of the things that make declarative languages good, though. Good Declarative languages allow composition - Having a base object, adding properties to it, overriding others. Ansible handles none of that in it's playbook syntax or it's vars syntax. In the role and module syntax, sure, but they're turing complete anyway.

Post by bpchaps » Thu, May 26, 2016, 8:44 PM UTC

devy wrote: post #72

bpchaps wrote: post #62

Earlier quoted context omitted.

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.

> 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…

  [0] $ man salt 2>/dev/null | wc -l
  140905

Post by technofiend » Thu, May 26, 2016, 9:02 PM UTC

wyaeld wrote: post #75

technofiend wrote: post #73

Earlier quoted context omitted.

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.

its in 2.0, which is available on RHEL

Post by ymse » Thu, May 26, 2016, 9:27 PM UTC

bpchaps wrote: post #76

devy wrote: post #72

Earlier quoted context omitted.

> 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…

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/nu…

    $ man puppet
    PUPPET(8)                Puppet manual                         PUPPET(8)

    NAME
       puppet

       See ´puppet help´ for help on available puppet subcommands