Red Hat releases Ansible 2.3 with network automation capabilities | Hacker News Reader

Red Hat releases Ansible 2.3 with network automation capabilities

sdtimes.com

83 pointsrbanffy25 comments

Now if only they could merge in modules that have been sitting in Pull Requests for months at a time. I submitted a module that has been requested since 2015 and it can't seem to find its way into the main project (https://github.com/ansible/ansible/pull/22097)

Also there are currently over 1000 open PR's. RH needs to devote more bandwith to community integration then they have been.

Or they could focus on making sure the code is solid.

Accepting thousands of modules from random people has downsides on the maintainability of the project and the consistency of the user experience.

Ansible by nature is a lot of independent modules doing different things. It is always a tough call to decide what goes in and what doesn't go in, and the project could go pretty bad quickly if they start merging anything.

(Ansible lead here) As I responded to a similar comment on Twitter the other day, part of the issue is our volume. When I looked, we had merged 395 PRs in the last month (via github pulse), which is ~33/day, assuming we work every day (which some of us do). That also includes a large period of time in which we were in a feature freeze for 2.3, meaning we weren't merging things in for a bit of the time. That's still about 3 prs per day per team member working on the code on top of everything else we do. This does not take into account the triaging of new issues, dealing with existing open issues, the mailing list, IRC questions, running public meetings... We've grown the team quite a bit (and are continuing to do so), but you can only do so much so fast.

We have recently enhanced ansibot to automerge PRs much more quickly without a core team member needing to be in the loop (the community is responsible for getting things automerged), so this will hopefully help even more so with getting PRs merged.

As for your PR, I'm a little confused as it says it was submitted on Feb 28th? Was that moved over from one of the modules repos? If so, I couldn't find any references to `iam_managed_policy` in either the -core or -extras repos.

the initial request for managed policy support dates back to 2015. I finally got around to cleaning up my module and publishing it this year, but its been a long wait for some of the fringe bits of AWS to be able to be managed under ansible.

I also submitted a very simple module which might benefit from improvement by other developers in a PR. It just integrates Facebook's osquery with the Ansible facts.

I'm pretty sure it is nothing special. It was my first Ansible module and later on I discovered the library pattern (putting modules in ./library makes them accessible to ansible and ansible-playbook).

So I propose to have a more open ansible-library repository which users would be able to git clone or symlink to ./library. This should increase eyeballs on the new modules and maybe we could have a voting system in place to promote modules from there into the main repository.

Just out of curiosity, how is that module tested? It is one new file without a single test. How people know it works and change it knowing it still works?

There isn't a very good automated testing strategy for ansible modules. If you look in the documentation there are examples that should exercise all the code paths, so a future developer can validate it is still working by running it with those examples. So much of the logic of the module requires you to interact with boto that without a substantial mocking of that interface the tests would be effectively worthless.

Great!

But I wonder if/when Ansible Tower is going to get open sourced.

I remember some posts from RedHat people saying it'd be open sourced "very soon" ~1.5 years ago, but other than a landing page nothing has come of it...

We're using Jenkins instead but an open source release would sure be nice.

I've also heard of people using Rundeck.

ARA is useful for these sort of setups: https://github.com/dmsimard/ara

Someone from the Ansible team came to the local PUG meetup recently. They said it would be open sourced this year.

I was always surprised that Ansible didn't ever think to offer Tower as SaaS. I'd like to use it, but I'm really not interested in managing another box just for it.

This is really a thing that cannot be SaaS. You can't allow a remote software in a random place in the world ssh to your servers as root and execute random commands.

Hosted Chef is effectively this. Not that I think it's a good idea.

That just shows a lack of imagination, I can think of many ways to do it securely. Also, in many cases there is no longer any "on-site" location to run things from. If your servers are in AWS, your code in GitHub/BitBucket/AWS CodeCommit, your CI pipeline is in Circle/Travis/Codeship/AWS CodePipeline... running an Ansible playbook on a service professionally managed by Red Hat is fine. It's likely to be better managed and more secure than your average never-been-patched ad-hoc on-site Jenkins box or your devops guy running the play from his MacBook.

Just because it's possible doesn't mean it's a good idea.

RFC 1925: https://www.ietf.org/rfc/rfc1925.txt

        With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

Unless you are doing deploys from on-prem, to on-prem servers (a shrinking market), I think it is a good idea for the average company to let a professional company manage the infrastructure for them. I've never seen a self-hosted git, CI, etc. be more reliable or secure than the SaaS equivalent in any of the companies I've been, big or small.

> I've never seen a self-hosted git, CI, etc. be more reliable or secure

E.g. a self hosted subversion repo sitting on a network share is 100% reliable. What's so special about such things. It's a solved problem.

Here is a more detailed article from Ansible: https://www.ansible.com/blog/network-device-authentication-w...

I wonder why they didn't just work on improving integration with napalm.

https://github.com/napalm-automation/napalm-ansible

https://napalm.readthedocs.io/en/latest/index.html

probably because NAPALM is in base SaltStack

Official press release from Red Hat is at [0].

[0]: https://www.ansible.com/press/advanced-network-automation-wi...

> This includes enhanced network capabilities such as persistent connections framework, which allows for one SSH connection to stay active across multiple Ansible tasks. This reduces the total time for completion, and according to Cramer, it improves performance as well.

Can confirm, this helps tremendously.

How is this different from pipelining?

Pipelining is a method to stream the module code over the ssh connection straight into the interpreter without first writing it to disk.

Connection persistence is identical to openssh's controlpersist mechanisms to reduce the amount of setup/teardown on connections. The networking modules in ansible make use of paramiko for ssh, which could not take advantage of controlpersist. In ansible 2.3 we wrote a tool to emulate controlpersist for paramiko.

I tried to browse to the article using the link on the headline and was presented with an odd message:

Bad Request

Your browser sent a request that this server could not understand.

Request header field is missing ':' separator. Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chro Apache/2.4.7 (Ubuntu) Server at sdtimes.com Port 80

A better link is: http://sdtimes.com/red-hat-releases-ansible-2-3-network-auto...

Looks like the poster is trying some special tracking that is breaking on Chrome on Mint.

Reply on news.ycombinator.com