101–110 of 173 posts
Earlier quoted context omitted.
Also "on" and "off", and variations. "y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF" https://yaml.org/type/bool.html
"NO" being false is particularly fun: - languages: - en # english - is # icelandic - no # norwegian - ja # japanese - fr # french [{"languages": ["en", "is", false, "ja", "fr"]}]
Earlier quoted context omitted.
Ansible deserves some credit at least. It tried to avoid the pitfalls Chef and Puppet fell into, which is having a DSL that allows arbitrary logic, i.e. basically just a Ruby script. These become horrible to trace and debug. Ansible only allowed conditionals or loop constructs in some well-defined places, which actually does help when trying to comprehend Ansible playbooks. (Although one might still argue a strict DS…
From my perspective--as somebody who slings this stuff a lot --what you describe as a "pitfall" is what I describe as "how to make things work." I don't find that Chef cookbooks are all that onerous to debug at all. Cleanly-written Ruby (and you can write Chef cookbooks in very clean Ruby, it really isn't that big of an ask) isn't hard to trace and in the extreme case--and this has happened twice in my career--I just…
you can, but in reality, this doesn't happen. especially for people who just want config management, and not to learn Ruby, or exactlty the "sysadmin/developer divide" as you've so aptly put it. all I got from Chef was loathing Ruby and all it's magic.
anyhow, the point was to illuminate how/why Ansible came about. i don't really like or use Ansible much anymore.
You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...
My company's scripts have lots of "if fail, try two more times, and hope it succeeds" logic as a result. -_-
Earlier quoted context omitted.
From my perspective--as somebody who slings this stuff a lot --what you describe as a "pitfall" is what I describe as "how to make things work." I don't find that Chef cookbooks are all that onerous to debug at all. Cleanly-written Ruby (and you can write Chef cookbooks in very clean Ruby, it really isn't that big of an ask) isn't hard to trace and in the extreme case--and this has happened twice in my career--I just…
> and you can write Chef cookbooks in very clean Ruby you can , but in reality, this doesn't happen. especially for people who just want config management, and not to learn Ruby, or exactlty the "sysadmin/developer divide" as you've so aptly put it. all I got from Chef was loathing Ruby and all it's magic. anyhow, the point was to illuminate how/why Ansible came about. i don't really like or use Ansible much anymore.
I get that not everybody is a Ruby person. "Chef but in Python" probably would have done pretty well. But it is genuinely not that difficult and probably more widespread than people give it credit for being.
Alternatively, if you're programming and you want a structured data format, use S-expressions! They are basically tailor-made for exactly this problem. (gitlab:assets:compile #%dedicate-no-docs-pull-cache-job (image "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.5.3-git-2.18-chrome-71.0-node-8.x-yarn-1.12-graphicsmagick-1.3.29-docker-18.06.1") (dependencies setup-test-env) (services (docker stable-dind)) (var…
This is exactly the problem with S-expressions. No-one is willing to define what "good enough" looks like and create a fixed, reusable standard for how you represent these things. Instead everyone hand-rolls their own, subtly incompatible variant.
> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…
Another potential option, is Lightbend Config https://github.com/lightbend/config It adds includes/inheritance, substitutions, unit of measure parity , comments , and few other things -- on top of JSON. does not have if-logic, loops, or arbitrary functions, however. On plus side, the library is available in a number of languages, easily embeddable. And there is an IntelliJ plugin for it, to color the syntax of the co…
Yes, a lot of YAML abuse consists of trying to pretend code is config, and that problem exists for any config format. However YAML specifically is also a uniquely bad config format, even when used for plain config; too many obscure corner cases (e.g. the abbreviation for Norway turning into false, port mappings turning into times when the ends in a number...)
While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy . It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. I don't w…
All of that applies to config, or to any other solution to the problem, because the complexity is (usually) inherent to the business problem you're solving. The difference is that in config, none of that tooling is available. If I put some complex logic in config I still want to version control it and debug it and test it - but I can't. Give me a real programming language where at least I have standard tools available for managing complexity.
> Aside from that, crafting configuration and performing operations should have a real user interface.
Code is the best user interface anyone has ever come up with for specifying complex logic, precisely. Mathematicians use something very similar, not because maths is done on computers but because they have the same need to communicate precisely. Lawyers use a "plain english" language that ends up being more verbose and less readable. Any "visual" format, including every configuration UI I've seen in practice, is even worse.
Earlier quoted context omitted.
I can't tell if this is sarcastic or not, but it doesn't seem to be. Binary computers are precise in their operation; that's why we use programming languages: to make it easier to create the underlying instructions to perform calculations. You are assuming that human answers to human questions in imprecise human language can even be converted to binary instructions. If it were that easy, general AI would've already b…
You're taking it too literally/assuming too much. It is super easy. Watch. $ awscli s3 ls Unable to locate credentials. You can configure credentials by running "aws configure". That is stupid. Let's fix it. #!/bin/bash [ -r .awssettings ] && . .awssettings [ -n "$USERN" ] || read -p "What is your username? " USERN if [ ! -n "$PASS" ] ; then read -s -p "Enter your password: " PASS ; echo "" fi [ -n "$REGION" ] || rea…
Having simple, predictable, consistent behavior from our tools is far better than trying to guess what the user wanted.
Earlier quoted context omitted.
I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?
From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…
-Define the desired state of your system in a declarative way. This requires a DSL, and some tools such as Ansible and Kubernets use YAML as that DSL.
-The configuration engine (Kubernetes, Ansible, Chef, Salt) will converge the system to the desired state in an idempotent way using the DSL.
-Many systems have mostly the same config and many systems also run in environments that are mostly similar but with some differences. It doesn't follow the DRY principle to create separate but mostly identical desired state configurations for every system/environment, so we need programming primitives and templating tools to accomplish it. It's no less valid than a web app templating HTML for instance.
It's easy to conflate "mixing programming with configuration" with "using programming to solve configuration generation."