3 ms·

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

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.

tgv 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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
gchamonlive 1y ago
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 1y ago
  > 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.
  - dreamcompiler 1y ago
    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 1y ago
      Curious about this myself!
      - onraglanroad 1y ago
        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.
Y-bar 1y ago
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 1y ago
  Only if you use Kubernetes, because it’s YAML 1.1 all the way.
  - Diti 1y ago
    Forgot to add a source: https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024 https://github.com/kubernetes/kubernetes/issues/34146#issuec...
    - Y-bar 1y ago
      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.

tgv 1y ago

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 1y ago
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 1y ago
  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 1y ago
    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

gchamonlive 1y ago

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 1y ago
> 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.
- dreamcompiler 1y ago
  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 1y ago
    Curious about this myself!
    - onraglanroad 1y ago
      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.

Y-bar 1y ago

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 1y ago
Only if you use Kubernetes, because it’s YAML 1.1 all the way.
- Diti 1y ago
  Forgot to add a source: https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024 https://github.com/kubernetes/kubernetes/issues/34146#issuec...
  - Y-bar 1y ago
    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.