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

31–40 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#31

Post by ausjke »

acveilleux wrote: post #27
ausjke wrote: post #24

Earlier quoted context omitted.

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.

It can do truly agent-less using raw mode (which is basically raw SSH). That said a version of Python 2 can be relied upon to be available on almost all Linux box.

yes that's what I used as my target is a resource-restricted router that does not have space for any python, that's the only occasion you can call it agent-less, but most people are not using that mode.

Re: Ansible 2.1 Released, with Network Automation, Containers

#32

Post by bovermyer »

coredog64 wrote: post #25
bovermyer wrote: post #22

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.

Not specifically Rundeck, no. I don't think anyone has written a blog post on that yet.

Depending on how you're using Jenkins, Rundeck may not be a feature-for-feature replacement. You'll have to weigh Rundeck's feature set against your specific requirements.

Re: Ansible 2.1 Released, with Network Automation, Containers

#33

Post by devy »

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 itself, is a deal breaker for me.

[1]: https://github.com/ansible/ansible/issues/5797

Edit: Downvoting me doesn't make this issue go away. What was requested is a simple basic debugging requirement - any mature syntax tree parsers should be able to do it.

Re: Ansible 2.1 Released, with Network Automation, Containers

#34

Post by brudgers »

vacri wrote: post #20
movedx wrote: post #14

Earlier quoted context omitted.

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…

Why not just roll back while you're testing the fix? No need to be suffering unnecessary downtime while you hunt, fix, test, package, stage, and deploy the hotfix. Rolling back takes you to a version that has already passed all stages.

John Wilkes of Google talks about this problem with Jeff Meyerson [1] and how it relates to the choice to use or not use containers. The spoiler is that container management tooling allows separation of infrastructure builds from deployment: a configuration problem when building a container happens on the build server instead of while a script is running on machine in production. His argument is that when a container deployment to production fails, the state of the machine is readily known (new bad container) versus an more complex state when a scripted build fails part way to completion.

And a container management tool can facilitate handling a failed distribution automatically via rollback to a previously deployed working container.

http://www.se-radio.net/2016/01/se-radio-show-246-john-wilke...

Re: Ansible 2.1 Released, with Network Automation, Containers

#35

Post by therealmarv »

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

Re: Ansible 2.1 Released, with Network Automation, Containers

#36

Post by therealmarv »

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 would be that whole Ansible would use rockstable libcurl instead of the requests library which has problems with Certs on (not so) old python versions.

Re: Ansible 2.1 Released, with Network Automation, Containers

#37

Post by thenewwazoo »

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

I'm curious to hear this too. We use Ansible to manage a fleet of a few thousand hosts, and runs take hours and hours and hours.

Re: Ansible 2.1 Released, with Network Automation, Containers

#38

Post by bcoca »

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…

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.

Re: Ansible 2.1 Released, with Network Automation, Containers

#39

Post by bcoca »

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.

Re: Ansible 2.1 Released, with Network Automation, Containers

#40

Post by earless1 »

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…

Keeping a system down while waiting for a hotfix is not an option for most operations. Rollbacks have their place and hotfixes have their place.
Post reply on HN