24 ms·

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

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?

pram 4y ago
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?
- deafpolygon 4y ago
  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.
- renox 4y ago
  Itself implemented in a new language not yet at version 1..
0cf8612b2e1e 4y ago
Is Ansible slow because of Python? I had always assumed the performance was due to excessive network roundtrips.
- JediPig 4y ago
  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.
- Octabrain 4y ago
  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".
- thyrsus 4y ago
  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.
Jedd 4y ago
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.
- tubs 4y ago
  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.
cdogl 4y ago
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.
matu3ba 4y ago
> 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).

pram 4y ago

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?

deafpolygon 4y ago
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.
renox 4y ago
Itself implemented in a new language not yet at version 1..

0cf8612b2e1e 4y ago

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

JediPig 4y ago
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.
Octabrain 4y ago
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".
thyrsus 4y ago
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.

Jedd 4y ago

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.

tubs 4y ago
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.

cdogl 4y ago

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.

matu3ba 4y ago

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