[parhamn]

Hashicorp has very cool stuff but I am not a fan of the config language they use on all their projects. It’s fine when I’m in an infrastructure type role and recency recall is fine but when Hashicorps tools are in my periphery it is a pain. Anyone share this? I guess the alternative is templated tomls/yamls/pseudo-jsons. Wish we’d all agree to one templated configuration format.

[chrizel]

I myself would love to see more usage of HCL... after writing a lot of Terraform configurations, it feels so much nicer for me than any JSON or YAML/Helm configuration I have written to this day. We should agree on some kind of HCL-based industry standard and leave all these workarounds via JSON/YAML behind us... e.g. doing Helm logic with these Go templates just looks like a step backwards after writing Terraform HCL code for the last 2-3 years.

I understand JSON as a simple interchange format between systems, and is here to stay, but I don't understand all this YAML stuff, with all its quirks, from the K8s/DevOps people, when we have the much nicer HCL...

For anyone not used to HCL: https://github.com/hashicorp/hcl

[RulerOf]

The thing I dislike about YAML is how unwieldy it gets and how quickly that happens. "Simple" YAML files tend to be half a dozen pages long.

HCL is more information-dense.

[cbushko]

I too prefer HCL to YAML and especially to helm templating.

Loops and conditionals in HCL could still use some real work though. They are still clunky to work with.

[Aeolun]

I liked HCL until I did some infra writing in Pulumi Typescript, and now I just want all my config files to be code.

[0xbadcafebee]

> Wish we’d all agree to one templated configuration format.

If you mean a standard configuration file format, that has almost never happened in the entire history of computing. There are standard data formats, sure, but to standardize a configuration file, all the applications need to be limited to the functionality expressed in a single config file format. Most applications hate that, because they want to add infinite features, and none want to wait to standardize some new version of a config file in order to release their features. (If they release before the config file changes happen, now you have a vendor-specific extension, which means waving goodbye to standardization)

The following are the only configuration file formats I am aware of that have been standardized:

  - bind zone configuration
  - inittab

Crontab isn't standard because different crons have different features. passwd, group, shadow, etc aren't standard configurations because they are actually databases. And anything else which goes over the wire instead of a file is a protocol, not a configuration.

Now, it's still not a bad idea to have standardization. The trick is to make it so they can change their configuration, but still be compatible with each other, and the general way to do that is to abstract the configuration elements via schemas. That way you can have the same basic functionality for each app, but they can define it however they want so that it can be re-mapped or interpreted by a different program.

However, that is in no way simple for a regular user to use. So to convince app developers to have a "standard configuration format", you need to reframe the value proposition. What's the value add? If you say it's just to a user can use one config file on many competing products, the developers won't care about what, because they want you to use their product, not be able to move to another one. If instead you reframe it as "extensible language for integrating and composing multiple independent pieces of software/functionality into one distributed system", then their ears might perk a bit. Basically, reformulate the proposed solution as a language to compose programs, like Unix pipes, but slightly more verbose/abstracted. The end result should be able to be read by any program supporting the config format, and "declaratively" (modern programmers love this ridiculous cargo cult) compose and execute distributed jobs across any system.

[znpy]

you basically described xml.

not sure I want to go back to that.

[sneak]

There was pretty broad ad hoc standardization in dos/windowsland on the ini-file format, which was broadly formalized as toml years later.

[0xbadcafebee]

Those are really data formats, not configuration. Their only features seem to be expressing simple data in different types and structures. The only advantages toml even advertises are types and mapping to hash tables. Those are all things computers appreciate, but humans need more nuance and functionality.

[alias_neo]

I find it particularly hard to manage Vault from the CLI. I deployed it some time ago and set up a bunch of backends, I don't recall the names of things or how I configured them and I want to backup that config to replicate it.

The auto complete will give you the top level command and that's it.

I haven't looked too hard because I got fed up, but i just want to dump the entire config so I can replicate it without having to remember each thing I configured.

[RulerOf]

I've been there. You basically want to be able `cd` into vault and list the contents interactively, but you can't.

While the Web UI is probably the best vault explorer available, you might want to take a look at Vaku[1].

[1]: https://github.com/lingrino/vaku/blob/main/docs/cli/vaku.md#...

[alias_neo]

Thanks, I'll check it out.

[ddreier]

We use Terraform to manage as much of the configuration of Vault (and Consul and Nomad) as we can. The provider is pretty good.

This makes it a lot easier to get a 1000ft view of the configuration.

[alias_neo]

This is ultimately my goal. Our current state has been prototyped iteratively over a year or so. The goal is to replicate and document the current state so that we can automate it such as with Terraform.

Unfortunately, unlike, say Kubernetes, which encourages a declarative approach, learning to integrate and use Vault comes with a lot of imperative operations, none of which is stored anywhere for reuse.

[gen220]

Even better, a standard API that you can create dynamic config against. :)

My best experience writing config files has been with Aurora config files for mesos deployments in pystachio-Python.

Once you’re used to using a real programming language to write/generate config, you never want to go back to YML.

[alephu5]

It's really frustrating for me that there's no way easy way to use YAML/JSON for configuring hashicorp products. It's supported at a low-level, but not from the CLIs for some reason...

I really like Dhall as a configuration language and use it across my whole system, so it's a shame I'm forced to use HCL or write a dhall backend for it.

[tempest_]

I just use JSON for all hashi config, you don't get comments but it is less mental overhead for me to keep track of.

[sneak]

Do their tools not support json5? That seems like an omission to me, if so.

[ascendantlogic]

> Wish we’d all agree to one templated configuration format.

I'm going to post the obligatory XKCD comic because your comment is exactly what this was created for: https://xkcd.com/927/

[Cederfjard]

Not really, the parent wasn’t suggesting developing a new standard, only settling on one.

[ascendantlogic]

if all the current ones haven't been good enough then I think its implied that a new one would be created.

[Cederfjard]

Well I disagree, if nothing else for the fact that they never expressed that none was good enough, just frustration that there are too many (or more than one, really). Perhaps they’d be happy if everyone just settled on YAML or something.