Hacker News Reader

Comment by thyrsus | Hacker News Reader

This looks great. The first use case that occurs to me is to accelerate pieces of our horribly slow Ansible scripts - but I'm probably the only one on our team who's interested in making the investment in learning a new language, and dealing with the bespoke code. How do I generate the required enthusiasm?

View on HN

Personally I think that would be a pretty hard sell. Writing custom code, presumably for things used in production, in a new language that isn't even at version 1?

Plus slow & steady wins the race.

It's better to use predictable code in production and this language hasn't even been battle-tested yet.

Itself implemented in a new language not yet at version 1..

If you're committed to, and enjoy the combination of, Python & YAML & Jinja2 - but don't enjoy the architecture, performance, and sharp edges of Ansible, you may want to review Saltstack as a config management tool. It's not a drop-in replacement, of course, but it's much closer to where you are now than the traditional two alternatives.

However, as others have observed to you, it's not a good idea to replace your current functional Ansible menagerie with a new unstable language + no framework.

Is there someone alive who enjoys that particular combo?

It's probably the set of three words most likely to send me into a corner, crying.

Is Ansible slow because of Python? I had always assumed the performance was due to excessive network roundtrips.

bingo. there is a flag you can set that eliminates most , if not all. It's not slow cause it's written in 'python'. It's slow because of safety.

From my experience, it is not always just the network. Ansible can be slow in operations such as copying files between directories on the remote target. I suffered from this a couple of years ago and the solution I implemented was to delegate the copy operation to a bash script and leave Ansible to just take care of uploading that script and run it passing the configured parameters.

Anyways, if the network is a problem I strongly recommend to have a look to "Ansible pull".

We're using ansible-pull. Aside from occasional access to NFS mounts, there's a minimum of network traffic. E.g., the git retrieval is usually: I've got version x. That's current? Thanks, we're done. The time is spent executing Ansible modules on the local system. 200+ tasks ok, 200+ tasks skipped, maybe 10 changed. That takes between 5 and 20 minutes. I have an unsubstantiated suspicion that the large dictionary representing the package inventory is a contributor - systems with fewer packages seem to work faster.

> How do I generate the required enthusiasm?

Find a good use case that justifies using an unstable language. This is typically internal developer tooling or testing systems.

Personally I would love a language with better type+test system than python for shuffling json around and math stuff. Python's dict functionality feels like a big fat hack (recusive merging, splitting json, detection of subdict etc) and likewise the xml stuff (there is no guide what xml tooling to use and what is broken in what python version and a third party package is better than libstd).

First, establish that the language is the issue. Measure. It's difficult for me to imagine a situation with Ansible scripts where the performance bottleneck is the raw performance of the python runtime.

Reply on news.ycombinator.com