6 ms·

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/saltstac

• k__ 8y ago
  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?
  • cube2222 8y ago
    Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.
    • k__ 8y ago
      Sure thing, but Jinja looks like a garbage fire. Why couldn't they use a regular programming language to create the markup? I mean this is done with HTML and JS all the time.
      • linuxftw 8y ago
        jinja is great, IMO, and well suited for it's intended purpose. jinja is in wide use in the python community.
        • weberc2 8y ago
          Maybe jinja is well-suited to whatever its intended purpose is, but it's not well-suited for programmatically building markup. Using a dynamically typed scripting language to generate the markup at least has the benefit of allowing you to define appropriate semantics via functions ("give me a blob of YAML that represents a Kubernetes service with these parameters"). Sure, you can probably build your own concept of functions on top of Jinja, either by embedding them or building your own paradigm on top of Jinja's template inheritance, but it's a hack either way.
          • linuxftw 8y ago
            Well, I think it was originally designed with server-side html templating in mind. It works great for that purpose. In the case of thread OP, that template is pretty messy, yes. In ansible, I would just create a custom module or action plugin in python to spit out whatever it is I need. I don't know how flexible salt is in this regard, but ansible is quite flexible. For simple cases, jinja works great if you're just doing a find/replace type operation in yaml.
    • jfoutz 8y ago
      With salt at least, that .sls file can just as easily be python. Just return the structure you need.
      • simtel20 8y ago
        Thanks for pointing that out. It's exhausting reading people in this thread getting very excited and demonstrative about the fact that a flexible system like salt provides a way to do this that results in a serialized data stream. They assume that they know better how this should be done, and posture about their superiority vs. some kind of straw man.
    • weberc2 8y ago
      We don't have to--you can generate the markup language with a scripting language and end up with something that is quite a lot cleaner. I've been toying around with Starlark as a yaml generator for Docker Compose, CloudFormation, and Kubernetes. This ends up working out a lot more nicely in practice than Helm's templating solution or CloudFormation's nested stacks.
  • q3k 8y ago
    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 learn (bastardized) programming concepts. It'd take much more effort to turn them into a 'real' programmer, learning a language from scratch, practicing that, and only then introducing some tool in the form of a library.
    • scirocco 8y ago
      Would you expect all sysadmins to become programmers?
      • q3k 8y ago
        Would it be beneficial? Yes. Is it necessary for most cases? No. I do think, however, the moment when you infrastructure becomes defined by code (eg. you start using any CM system) then you should be training your sysadmins to program more and duct tape existing solutions less. Operations become vastly easier to scale and maintain if you can defer their logic to actual services with clearly defined business logic rather than a mess of ansible configs and bash scripts.
      • k__ 8y ago
        Maybe some will? My take is: The complex admin work will be going to the cloud providers. The rest (besides some niche stuff) will get so simple a programmer can do it on the side. Admins that don't learn to program are left behind. Only those who have some cushy full time employment, were they can't be let go, will remain.
        • merlincorey 8y ago
          > Admins that don't learn to program are left behind. Only those who have some cushy full time employment, were they can't be let go, will remain. While I personally am a Software Engineer + Systems Engineer combination perfect for modern Devops... I do not agree with you one bit. There will always be a place for non-programming systems administrators -- especially as we get more and more systems over time. Will those administrators be able to /scale/ to managing 100s or 1000s of system without learning some sort of programming language or configuration management system? Probably not. However, there are plenty of businesses out there that only have a handful of servers and services which can totally (and more cheaply) be managed manually. Automation has an up-front cost that doesn't always make sense for the business to spend.
  • tannhaeuser 8y ago
    YAML = YAML aint't markup language Please don't give markup a bad name because of YAML, or the clusterfuck linked by GP.
    • k__ 8y ago
      You got me wrong here. I don't think markup languages are bad. I just don't understand why someone would create such a "clusterfuck linked by my GP" If you re-invent a programming language in markup, you basically get a new custom programming language that "probably" can do the same as another non-custom programming language, but without the benefit of many people already know them. Why not integrate something like Lua or Dyon instead of YAML or XML?
      • tannhaeuser 8y ago
        I know what you mean, and agree with you ;) The inflationary use of the term "markup" just bothers me, when it denotes a very specific thing that's been in use since before computers existed.
  • crdoconnor 8y ago
    Because it's often really hard to know what aspects of your product needs the flexibility of code and what benefits from the simplicity of configuration. I wish we started analyzing this as the hard problem it is rather than getting angry that people didn't always make the right decision by correctly anticipating how their software would end up being used.
  • scruple 8y ago
    Because their bosses dream up scenarios where customers will be generating config files to be used as templates, etc..., and they're just trying to solve whatever problem was put in front of them and "we'll use YAML", IME. Of course, those scenarios never play out, the thing is bastardized, some new responsibility gets created for some new role where it's their job to handle the template generation on a per customer / per site basis, and on and on we go.
  • viraptor 8y ago
    You can use python to create that directly. Jinja is just another, default way to achieve this. Why? Because it turns out it's much cleaner that way. (I've done both)
• Spivak 8y ago
  Where's the abuse? They're just generating a YAML with Jinja2. Is there something egregious about their YAML structure?
  • zaphar 8y ago
    It's really easy to generate invalid YAML with a templating language if you aren't careful. If you like tooling that protects you from yourself and others mistakes then using a template language to generate YAML is going to ring warning bells for you.
    • simtel20 8y ago
      True, but once you get it right once, it's really easy to generate the correct yaml over and over again because the input is not unknown random data.
      • zaphar 8y ago
        The problem is that in practice you are modifying these somewhat frequently and if you aren't careful one of those modification will result in a production outage.
        • simtel20 8y ago
          For the things that change frequently, guardrails can be built (extra testing, extra safety). But over time most configuration ends up stable, with the changes not being wild-wested, in my experience.
  • ansible 8y ago
    Because the linked example is code, not just configuration data. And if I'm writing code, it should look like code you'd actually want to read and edit. Not something with hacked-on delimiters {%- all over the place %}.
• yongjik 8y ago
  Yep, saltstack is a dumpster fire. Each jinja template can call arbitrary Python functions, and usually brings in external data from somewhere, so if something fails you have a jinja template that imported arbitrary data into a YAML format which defined multiple action items that are executed in some hard-to-understand order and good luck figuring out what went wrong where. Jinja/salt usually wouldn't even tell you what line of the original script caused the error. My company's scripts have lots of "if fail, try two more times, and hope it succeeds" logic as a result. -_-
  • actionowl 8y ago
    After years of using Salt (and contrinbuting upstream patches and PRs), I've finally given up on it entirely. There are too many reasons to include here but it indeed has turned from something useful and promising into a total dumpster fire.
• likeclockwork 8y ago
  Why would anyone generate YAML as a string when JSON is valid YAML and can be generated programmatically?! Why??