Live data from Hacker News

Ansible 2.1 Released, with Network Automation, Containers

redhat.com

61–70 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#61
I love and hate Ansible. It has simplified so many things for me, but also had some annoying bugs and regressions. Somehow I've lost trust in the codebase. Also performance is a showstopper. I need a tool to develop, I just can't wait > 10 min for an iteration. I usually end up modifying my server's config files manually and then build the Ansible templates.

Unfortunately I'm not aware of a better alternative.

Re: Ansible 2.1 Released, with Network Automation, Containers

#62
post #38
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…

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.

Re: Ansible 2.1 Released, with Network Automation, Containers

#63
post #59

Earlier quoted context omitted.

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.

It's also not that easy to get PRs accepted.

Re: Ansible 2.1 Released, with Network Automation, Containers

#64
post #46
post #19

Earlier quoted context omitted.

> Changing the contents of one file can take ~10 minutes. O_o That kind of simple operation just zipped by for me on Ansible 1.6, 1.8, 1.9, and 2.0. The only noticeably slow kinds of operations for me are generally the package installs (understandably). I don't use a ton of variables in my templates, though.

I have quite a few variables, yes. One of the files I change frequently is an external configuration file filled with credentials which is managed through variables. It looks something like this: {% for cred in credentials %} {{cred.key}}: {{cred.value}} {% endfor %}

hey, kind of off-topic, but wouldn't you be able to like this?

  {{ credentials | to_nice_json }}

Re: Ansible 2.1 Released, with Network Automation, Containers

#65

Earlier quoted context omitted.

We've found Rundeck to be a more flexible alternative to Ansible Tower, and Rundeck is open source: https://github.com/rundeck/rundeck

Not to hijack the thread, but any pointers to good resources to sell mgmt on Rundeck? We're currently using Jenkins(!?) for role, something that enforces a divide where developers are allowed to automate, but operations isn't.

Wouldn't the obvious way forward be to open Jenkins for your ops?

(That said, Rundeck is probably more straightforward use. You could trigger it from Jenkins.)

Re: Ansible 2.1 Released, with Network Automation, Containers

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

Every time I let the config management stuff slide slowly towards procedural, bad things have happened.

You want your config management templates to be as declarative as possible. "This is the desired final state", and that's it. Of course, in practice it's very hard to stay 100% declarative, but it's very good practice to try and keep it close to ideal.

Re: Ansible 2.1 Released, with Network Automation, Containers

#67

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

Definitely agree with this. I use the docker module extensively and found 2 regressions[1][2] that I went through the trouble of debugging down to a single commit, but still have no idea whether anyone is going to fix them.

I'm hoping now that they are done rewriting the docker modules, and considering they are using docker as a selling point for 2.1, they will be more proactive with these issues.

1. https://github.com/ansible/ansible-modules-core/issues/3219 2. https://github.com/ansible/ansible-modules-core/issues/3231

Re: Ansible 2.1 Released, with Network Automation, Containers

#68

Earlier quoted context omitted.

Not to hijack the thread, but any pointers to good resources to sell mgmt on Rundeck? We're currently using Jenkins(!?) for role, something that enforces a divide where developers are allowed to automate, but operations isn't.

I'm trying to parse your statement and I'm not sure if you want something to enforce that divide or if your complaint with Jenkins is that it enforces a divide between dev and ops?

Sorry for not being clear. We're using Jenkins because it was the shortest path to a solution. It's not easy for non-devs to use, so I'd like something that is ops friendly and won't cause the devs to want to repeatedly bang their head on the desk.

Re: Ansible 2.1 Released, with Network Automation, Containers

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

I've used Ansible quite a bit, and I could sometimes sum it up as, "the worst one, except for its alternatives".

I tend to think of Ansible as supporting a flexible combination of declarative and procedural approaches. Within a particular sequence of tasks, it's procedural. Those lists of tasks are typically combined into a role or the like that is typically more declarative in its application. Of course application of roles is actually procedural in that it happens in the same obvious order it's defined, but the higher level organizational constructs like roles have more of a declarative feel to me (I'd assume that's by design).

Re: Ansible 2.1 Released, with Network Automation, Containers

#70
post #67

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

Definitely agree with this. I use the docker module extensively and found 2 regressions[1][2] that I went through the trouble of debugging down to a single commit, but still have no idea whether anyone is going to fix them. I'm hoping now that they are done rewriting the docker modules, and considering they are using docker as a selling point for 2.1, they will be more proactive with these issues. 1. https://github.c…

Look at Chef. Its extensively unit tested in both the core client & server, but also the cookbooks associated with it. Check out the docker one for example https://github.com/chef-cookbooks/docker The interfaces and primitives for docker in this cookbook are great too.
Post reply on HN