[al_borland]

The Norway problem drives me a bit nuts.

In a lot of the Ansible documentation, yes/no are used instead of true/false. When seeing this in the official docs, I used it, figuring this was the preferred convention in Ansible. These days it now throws warnings or lint errors, so I’m updating it all over the places as I find it. Yet the Ansible documentation still commonly uses it.

[gchamonlive]

Ansible isn't a gold standard for docs. The docs are updated and maintained, but the underlying interfaces aren't consistent and that leaks to the docs. One can only wonder why, maybe different developers with different ideas for conventions without a style guide.

Ansible is a wonderful tool though, if you can excuse these idiosyncrasies.

[sofixa]

> Ansible is a wonderful tool though, if you can excuse these idiosyncrasies.

The only advantage Ansible has is how easy it is to start with it - you don't need to deploy agents or even understand a lot about how it works.

Trouble is, it doesn't really scale. It's pretty slow when running against a bunch of machines, and large configurations get unwieldily quickly (be it because of YAML when in large documents its impossible to orient/know what is where/at what level, or because of the structure of playbooks vs roles vs whatever, or because templating a whitespace-as-logic-"language" is just hell). It's also fun to debug "missing X at line A, but the error can be somewhere else". Cool, thanks for the tip.

So it's pretty great to get started with, or at a home lab. Big organisations struggling with it is a bit weird.

[gchamonlive]

I've had the opposite experience. A bit hard to setup, with ssh-agent, inventories and understanding what each module does, and creating specialized roles. So for quick jobs, plain bash with ssh wins most of the time.

But once ansible is set, it's easy to achieve parallelism when provisioning multiple instances.

Problem is that it requires lots of back and forth over ssh, so the more latency you have between the control plane and the target hosts the slower it'll be.

And yeah... Debugging is a pain. I wish I could write ansible in an actual language instead of having to fight multiple layers of indirection with ansible, jinja2 and yaml.

[dreamcompiler]

Seems like the right answer is "bootstrap your daemon installs with Ansible and then use something that scales better that runs on those daemons."

What are the best practices along these lines? What's the "something better"?

[TheTaytay]

Curious about this myself!

[onraglanroad]

I tend to use Ansible to set up for Puppet.

There's an Ansible provider for Terraform so you can do the whole thing in there.

[burnt-resistor]

Chef is easy to run in solo mode too, but too many people just religiously hate Ruby and the flexibility of imperative configuration. CINC is the debranded libre version.

[al_borland]

I found job slicing speeds up jobs dramatically. In a test I did recently it dropped the time from nearly 4 hours, down to 17 minutes, for an inventory of about 4500 hosts.

[tgv]

It depends on how they parse/decode/unmarshal the file. If they use a "generic" yaml parser, no will be translated to false. But if the parser knows the types of the data structure, or can be instructed not to replace certain strings, or has hooks, it can treat no as a string. So it might be that the linter doesn't operate like the parser.

[maxbond]

Halloween isn't for a few more weeks, but this framework for creating bespoke YAML dialects that can only be parsed by a specific implementation and with the correct type annotations will scare the pants off of your devops colleagues around the campfire.

(In case I haven't succeeded in hitting the right tone, this is intended to be good-natured jest and not snark.)

[tgv]

Well, JSON cannot represent dates (nor Sets, Maps, NaN, etc.), so quite a few applications with a JSON parser have their own conversion (e.g. seconds since epoch, string parsing, object with date fields). Is that a bespoke JSON dialect that scares the pants off?

Now, JSON is more suited for machine-to-machine, but YAML works fairly well for humans. It's a pity, but a few domain specific don't really hurt, since you can't copy some bit of YAML and paste it in an entirely different config anyway.

PS campfire story? "When we were still working in the old building, deep down in the cellar, there was a colleague who had been there since the early days. Nobody saw him arrive at work or leave. It was as if he was always there. One of the things he had written was a custom parser ... FOR YAML!"

[maxbond]

I'd say that isn't a JSON dialect because that's postprocessing applied after parsing, versus hooking into a YAML parser to change the semantics of how `no` is parsed. But it is a good point.

I did run into a project once with a very cool custom YAML parser to recommend how to recover from errors. I think you do have to type check all deserialization, and you should fail if you process a bool where you expect a string. Automatically fixing things can be very dangerous. But if you were going to do it, the way you described is the best way to do it.

> Well, JSON cannot represent ... NaN ...

Here's another horror story:

    >>> # Python 
    >>> json.dumps({"foo": float("nan")})
    '{"foo": NaN}'

    > // JavaScript
    > JSON.parse('{"foo": NaN}')
    Uncaught SyntaxError: Unexpected token 'N', "{"foo": NaN}" is not valid JSON

[Y-bar]

Has this really been a problem in the last ten years? Version 1.2 of the spec (if I recall) fixed it in 2009.

[Diti]

Only if you use Kubernetes, because it’s YAML 1.1 all the way.

[Diti]

Forgot to add a source: https://github.com/kubernetes/kubernetes/issues/34146#issuec...

[Y-bar]

Oh man. That issue is nine years old now and still open. And the referenced candiedyaml library was archived in 2022.

Sometimes the tech world moves at warp speed, sometimes it just treads water.