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

41–50 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#41

Post by calvins »

ausjke wrote: post #24
benhoyt wrote: post #12

Earlier quoted context omitted.

I think it actually makes sense for something like Ansible to use Python 2 because it's about controlling lots of remote machines on various Linux distros, and the idea is that it's agentless. If you suddenly have to install an "agent" (Python 3) on all the remote machines before you control them with Ansible, that wouldn't be great. On the other hand, Ansible itself could have a tiny bootstrap step which installs Py…

if it's _truly_ agent-less why do they care about the python version on the target, I feel that python target code is the agent? I might be missing something. Tried it a while ago, interested in developing tower-like management software(light-weight) using javascript as Tower is a bit too pricey for small/mid-sized customers.

> if it's _truly_ agent-less why do they care about the python version on the target, I feel that python target code is the agent?

"Agentless" means that it works by pushing to the machine and that there isn't an agent process already running on the target. It doesn't mean that there aren't any requirements on what needs to be installed on the target already.

Re: Ansible 2.1 Released, with Network Automation, Containers

#42

Post by zenlikethat »

movedx wrote: post #14
brudgers wrote: post #10

Earlier quoted context omitted.

Curious if "roll forward only" could create situations where a failed version change could place the system of interest in a non-functional state until the problem was diagnosed, the code revised, and an update released. If that's possible, I would have concerns about the infrastructure meeting the core needs of the business such as providing value to cutomers.

Your systems is already down, rolling back is the same thing, if not more effort than rolling forward. At least that's what I've always found. Another option is to have customers point at stage after it has been upgraded and if it all goes horribly wrong, a load balancer change should be enough to point people back at the older production environment. All this being said, problems in production shouldn't be a thing w…

> All this being said, problems in production shouldn't be a thing with configuration management, infrastructure as code (Terraform), and tests, not to mention three environments (development,test, stage - at minimum) to work your way through before pushing to production.

You'll still have problems, you've just automated them now. Those tools and approaches are great, but do they really prevent all production issues to the point where they "shouldn't be a thing"?

Re: Ansible 2.1 Released, with Network Automation, Containers

#43

Post by bcoca »

therealmarv wrote: post #36
mmgutz wrote: post #13

Unarchive module gets cert error on get.docker.com on Ubuntu 14.04 LTS. System Python is too old.

I also had this problems in the past with SNI certs. Very annoying old python bug, it's possible to fix old python but this makes no sense for an Ansible deployment http://stackoverflow.com/a/29099439/756056 Better approach: Use curl to download in some temp directory/file and then extract from there. Curl does not have this errors. Example: https://github.com/ansible/ansible-modules-core/issues/1716#... My dream wou…

we actually avoid the requests lib for this and many other reasons, we don't use libcurl as we try to avoid extra dependencies when possible.

The issue is more basic than requests, the actual python http/url and ssl implementations have these issues, we have patched and added warnings to indicate which minimal python versions you can use and have SNI work.

Re: Ansible 2.1 Released, with Network Automation, Containers

#44

Post by ausjke »

bovermyer wrote: post #22
hackerboos wrote: post #11

I hope open sourcing Ansible Tower is still on the cards after it was promised at a conference shortly after acquisition.

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

http://rundeck.org/plugins/ansible/2016/03/11/ansible-plugin... this looks interesting, anyone uses rundeck to replace Tower?

Re: Ansible 2.1 Released, with Network Automation, Containers

#45

Post by bcoca »

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).

speed has been both better and worse, so depends a lot on what your playbook is doing, size of your inventory, vars, etc

the only answer i can give you is: test.

We do try to keep decent performance, but this is not our main focus.

Re: Ansible 2.1 Released, with Network Automation, Containers

#46

Post by adamors »

vacri wrote: post #19
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).

> 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 %}

Re: Ansible 2.1 Released, with Network Automation, Containers

#47

Post by adamors »

bcoca wrote: post #45
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).

speed has been both better and worse, so depends a lot on what your playbook is doing, size of your inventory, vars, etc the only answer i can give you is: test. We do try to keep decent performance, but this is not our main focus.

I use around 1-3 variables per module and 4-5 modules per playbook. Other than that, the actual tasks are trivial (install package x etc.)

Re: Ansible 2.1 Released, with Network Automation, Containers

#48

Post by gerbilly »

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 known in my day as 'turdcap'.)

Re: Ansible 2.1 Released, with Network Automation, Containers

#49

Post by therealmarv »

bcoca wrote: post #43
therealmarv wrote: post #36

Earlier quoted context omitted.

I also had this problems in the past with SNI certs. Very annoying old python bug, it's possible to fix old python but this makes no sense for an Ansible deployment http://stackoverflow.com/a/29099439/756056 Better approach: Use curl to download in some temp directory/file and then extract from there. Curl does not have this errors. Example: https://github.com/ansible/ansible-modules-core/issues/1716#... My dream wou…

we actually avoid the requests lib for this and many other reasons, we don't use libcurl as we try to avoid extra dependencies when possible. The issue is more basic than requests, the actual python http/url and ssl implementations have these issues, we have patched and added warnings to indicate which minimal python versions you can use and have SNI work.

thanks for clarifying!

Re: Ansible 2.1 Released, with Network Automation, Containers

#50

Post by threatofrain »

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…

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.

Post reply on HN