Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ansible 2.1 Released, with Network Automation, Containers

redhat.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#51

Post by Kudos »

bcoca wrote: post #39
djrobstep wrote: post #9

I love Ansible, and have been using it since it was a humble little git repo with a single author. Unfortunately it's probably the most important python package that doesn't support Python 3, it would be cool to see it upgraded. Apparently the hold-up is supporting very old 2.x python versions because of RHEL.

Support for python3 has been on the roadmap, sadly most of the installed base of servers out there uses 2.x and in many cases 2.4 (centos/rhel5). This is NOT a switch from py2 to py3 we are aiming to support BOTH at the same time, this is not a trivial task (specially with 2.4) and will probably take us several versions to implement.

Several majors or minors?

Re: Ansible 2.1 Released, with Network Automation, Containers

#52

Post by willejs »

gerbilly wrote: post #48
devy wrote: post #33

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…

>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 (Also k…

RE: "I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design."

I've been a puppet user, and long time chef user, and recently been using ansible for a couple of projects, but I can't learn to like the 'language' at all. I feel like ansibles YAML syntax is just hiding the complexity of configuration management from you. Which at first as a novice ansible and CM user, or for small projects is great! You can be super productive, and anyone can understand it in your team.

However, as your systems get more complex, I feel like doing anything remotely complex with it produces confusing, hacky, unreadable ansible 'code'. Then you try to scale this working in a team, and try to do any useful testing, or re-use/extend/share any roles, your kind of doomed.

The reason I continue to use chef is because its a ruby DSL that you can easily extend, where anyone who can code; can write, test and understand. While I find Ansible is just templated YAML, and means you dont have to understand how to program.

I guess my point is, configuration management is kind of hard. I feel like people use Ansible because 'its easy', and I hear people say 'Ansible is easy' a lot. But in the end, Ansible, the tool chain, workflows and syntax will become just as complex as chef/puppet/saltstack when you operate it at scale.

Re: Ansible 2.1 Released, with Network Automation, Containers

#53

Post by gerbilly »

willejs wrote: post #52
gerbilly wrote: post #48

Earlier quoted context omitted.

>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 (Also k…

RE: "I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design." I've been a puppet user, and long time chef user, and recently been using ansible for a couple of projects, but I can't learn to like the 'language' at all. I feel like ansibles YAML syntax is just hiding the complexity of configuration management from you. Which at first as a novic…

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 language for reason 1 or some for reason 2.

Personally, I prefer that it's declarative, the file is supposed to describe the features the target system must have, and then the module, which is procedural, has to figure out how to make that happen on whatever target system is in question.

That separation keeps things clean, idempotent (most times) and neat.

I think procedural approaches _seem_ better because they are familiar to programmers, but they can become complex, non-idempotent and hard to debug.

Re: Ansible 2.1 Released, with Network Automation, Containers

#54

Post by TimSAstro »

adamors wrote: post #16

Can anyone comment on the speed of Ansible 2+? I have a bunch of playbooks that still use 1.8 and they are dog slow. Changing the contents of one file can take ~10 minutes. (Interestingly, running the entire playbook on a clean server is actually faster).

Have you tried turning on pipelining in ansible.cfg? Details here: http://docs.ansible.com/ansible/intro_configuration.html#pip...

Re: Ansible 2.1 Released, with Network Automation, Containers

#55

Post by Aissen »

sethish wrote: post #28
Aissen wrote: post #8

Does it support python3 yet ? Also, why do we have to install aptitude to do system updates ? It has been a long time since apt-get had bad resolution issues (and aptitude isn't installed by default anymore (has it ever been?)).

Aptitude is installed by default on Debian Jessie.

It's not on raspbian or Ubuntu Server.

Re: Ansible 2.1 Released, with Network Automation, Containers

#56

Post by bcoca »

Kudos wrote: post #51
bcoca wrote: post #39

Earlier quoted context omitted.

Support for python3 has been on the roadmap, sadly most of the installed base of servers out there uses 2.x and in many cases 2.4 (centos/rhel5). This is NOT a switch from py2 to py3 we are aiming to support BOTH at the same time, this is not a trivial task (specially with 2.4) and will probably take us several versions to implement.

Several majors or minors?

minors we release every 3-4 months (or plan to)

Re: Ansible 2.1 Released, with Network Automation, Containers

#57

Post by carrja99 »

It is unfortunate that Ansible has a complete lack of test cases around core modules and, as a result, people act surprise when they're broken in a new release.

For example see this fairly critical defect with the s3 module in today's release: https://github.com/ansible/ansible-modules-core/pull/3347

Re: Ansible 2.1 Released, with Network Automation, Containers

#58

Post by JTenerife »

bovermyer wrote: post #21
willthames wrote: post #6

Earlier quoted context omitted.

Revert your playbooks and roles to the version of your last good deployment, and redeploy. With good version control, role version management and idempotent library modules, this should be functionally equivalent to a rollback. There are plenty of caveats to the above (like the fact that the yum module won't downgrade [1], and you'll need reversible DB migrations) but that's basically the procedure. [1] https://githu…

This isn't quite accurate. It won't uninstall or remove things that a previous version put into place, unless you explicitly remove them before installing them as part of your playbooks/roles.

Exactly. This whole "declare your environment" thing with Ansible doesn't work.

I've completely mixed experiences with Ansible. Yes, it's easy to get started, but it's certainly annoying having to create playbooks for removing stuff to get a clean state.

Re: Ansible 2.1 Released, with Network Automation, Containers

#59

Post by devy »

therealmarv wrote: post #35
devy wrote: post #33

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…

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

Apparently it's NOT easy to implement according to Ansible dev above.

Re: Ansible 2.1 Released, with Network Automation, Containers

#60

Post by phunge »

gerbilly wrote: post #53
willejs wrote: post #52

Earlier quoted context omitted.

RE: "I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design." I've been a puppet user, and long time chef user, and recently been using ansible for a couple of projects, but I can't learn to like the 'language' at all. I feel like ansibles YAML syntax is just hiding the complexity of configuration management from you. Which at first as a novic…

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…

Agreed, this is a great way to think about it. I think Ansible is at its best when the modules handle the imperative stuff behind the scenes, and the playbook just declares. That's not always possible, but the modules are getting better and better.

FWIW I also found YAML to be very confusing syntactically at first; things got easier once I realized that it's basically 1-to-1 with JSON, and could convert to JSON to get intuition for the file structure (simple yaml2json script here: http://pastebin.com/TpjZLnLa). Thumbing through the book Ansible Up and Running also helped.

In the long run, putting a declarative idempotent layer atop the same old mutable infra is tough but a necessary compromise right now. It'll be great if the immutable-first tools of today (nixos et al) mature and we can leave this behind.

Post reply on HN