3 ms·

In parts of AWS / Amazon usage of YAML is forbidden. I sort of remember it was a contributing factor to a significant outage. A YAML config file was truncated

by ozten 5y ago

In parts of AWS / Amazon usage of YAML is forbidden. I sort of remember it was a contributing factor to a significant outage. A YAML config file was truncated and given partial configuration and otherwise falling back to default config, it put a system into a bad state. YAML was banned by some teams (and discouraged in most teams), because you can't detect a truncated file, like you can with XML or JSON.

angelzen 5y ago
Overreaction? Let's hypothetically consider yaml+, with the definition: yaml+ = yaml "\n" "." * easy to wrap a yaml parser and create a yaml+ validating parser. * easy to create a simple script to validate the end-of-file dot line. * easy to create a presubmit check to validate yaml+ * easy for an editor to syntax check the end-of-file dot line. Assuming there are other redeeming qualities of YAML, the truncated YAML problem can be solved with minimal effort.
- sa46 5y ago
  - Define a new file format, yaml-plus. - Create a parser for the new yaml-plus format across all supported languages. - Migrate all build processes to handle yaml-plus with the new parser. In a large-org, it's likely impossible to track down all the usages of YAML. Someone will have a bash script that hasn't been touched for 10 years that implements an adhoc YAML parser. - Modify the YAML mode for all supported editors to support the new syntax. This doesn't sound like minimal effort. Mandating that all new configs must be JSON (or similar, newer alternative like cue) is way easier since JSON already exists.
  - angelzen 5y ago
    Not really. Team X uses Java? Someone on the team takes 1 hour to create YamlPlus.java, submits to the monorepo. Now team X + all the other 100(0) teams that use Java have access to a yaml+ parser. Same with Golang, JS, Python, C++, cli check, presubmit check, and we are running out of supported languages. The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.
oxymoron 5y ago
I haven’t seen it explicitly banned, but the Operational Readiness templates does have a question about that which has to be answered for all product and feature launches. I guess some orgs may just have banned it outright though.
colejohnson66 5y ago
Since YAML tries to be a superset of JSON (it’s not, but it tries), wrapping your whole file in a pair of braces solves your truncated file problem. If the closing brace isn’t there, the parser will (should) error

by ozten 5y ago

angelzen 5y ago

Overreaction? Let's hypothetically consider yaml+, with the definition: yaml+ = yaml "\n" "." * easy to wrap a yaml parser and create a yaml+ validating parser. * easy to create a simple script to validate the end-of-file dot line. * easy to create a presubmit check to validate yaml+ * easy for an editor to syntax check the end-of-file dot line. Assuming there are other redeeming qualities of YAML, the truncated YAML problem can be solved with minimal effort.

sa46 5y ago
- Define a new file format, yaml-plus. - Create a parser for the new yaml-plus format across all supported languages. - Migrate all build processes to handle yaml-plus with the new parser. In a large-org, it's likely impossible to track down all the usages of YAML. Someone will have a bash script that hasn't been touched for 10 years that implements an adhoc YAML parser. - Modify the YAML mode for all supported editors to support the new syntax. This doesn't sound like minimal effort. Mandating that all new configs must be JSON (or similar, newer alternative like cue) is way easier since JSON already exists.
- angelzen 5y ago
  Not really. Team X uses Java? Someone on the team takes 1 hour to create YamlPlus.java, submits to the monorepo. Now team X + all the other 100(0) teams that use Java have access to a yaml+ parser. Same with Golang, JS, Python, C++, cli check, presubmit check, and we are running out of supported languages. The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.

oxymoron 5y ago

I haven’t seen it explicitly banned, but the Operational Readiness templates does have a question about that which has to be answered for all product and feature launches. I guess some orgs may just have banned it outright though.

colejohnson66 5y ago

Since YAML tries to be a superset of JSON (it’s not, but it tries), wrapping your whole file in a pair of braces solves your truncated file problem. If the closing brace isn’t there, the parser will (should) error