107 ms·

Hard disagree with replacing yaml with HCL. Developers find HCL very confusing. It can be hard to read. Does it support imports now? Errors can be confusing to

• geoctl 1y ago
  You can very easily build and serialize/deserialize HCL, JSON, YAML or whatever you can come up with outside Kubernetes from the client-side itself (e.g. kubectl). This has actually nothing to do with Kubernetes itself at all.
  • Kwpolska 1y ago
    There aren’t that many HCL serialization/deserialization tools. Especially if you aren’t using Go.
    • demosthanos 1y ago
      Given that we're apparently discussing an entire k8s 2.0 based on HCL that hardly seems like a barrier. You'd have needed to write the HCL tooling to get the 2.0 working anyway.
• dilyevsky 1y ago
  Maybe you know this but Kubernetes interface definitions are already protobufs (except for crds)
  • cmckn 1y ago
    Sort of. The hand-written go types are the source of truth and the proto definitions are generated from there, solely for the purpose of generating protobuf serializers for the hand-written go types. The proto definition is used more as an intermediate representation than an “API spec”. Still useful, but the ecosystem remains centered on the go types and their associated machinery.
    • dilyevsky 1y ago
      Given that i can just take generated.proto and ingest it in my software then marshal any built-in type and apply it via standard k8s api, why would I even need all the boilerplate crap from apimachinery? Perfectly happy with existing rest-y semantics - full grpc would be going too far
• dangus 1y ago
  Confusing? Here I am working on the infrastructure side thinking that I’m working with a a baby configuration language for dummies who can’t code when I use HCL/Terraform. The idea that someone who works with JavaScript all day might find HCL confusing seems hard to imagine to me. To be clear, I am talking about the syntax and data types in HCL, not necessarily the way Terraform processes it, which I admit can be confusing/frustrating. But Kubernetes wouldn’t have those pitfalls.
  • mdaniel 1y ago
    orly, what structure does this represent? outer { example { foo = "bar" } example { foo = "baz" } } it reminds me of the insanity of toml [lol] [[whut]] foo = "bar" [[whut]] foo = "baz" only at least with toml I can $(python3.13 -c 'import tomllib, sys; print(tomllib.loads(sys.stdin.read()))') to find out, but with hcl too bad
    • XorNot 1y ago
      Oh thank god I'm not the only one who sees it. People complain about YAML then go and use TOML.
    • eddythompson80 1y ago
      The block config syntax isn't that confusing. Nginx had it for years. this is the same as server { location / { return 200 "OK"; } location /error { return 404 "Error"; } } server { location / { return 200 "OK"; } location /error { return 404 "Error"; } } But because we know that nginx is a configuration language for a server where we define the behavior we want through creating a set of resources (servers in this example, but "example"s or "whut"s in yours) { "servers": [ { "locations": [ { "key": "/", "return": { "status": 200, "content": "OK" } }, { "key": "/error", "return": { "status": 404, "content": "error" } } ] }, { "locations": [ { "key": "/", "return": { "status": 200, "content": "OK" } }, { "key": "/error", "return": { "status": 404, "content": "error" } } ] } ] }
• znpy 1y ago
  > Hard disagree with replacing yaml with HCL. I see some value instead. Lately I've been working on Terraform code to bring up a whole platform in half a day (aws sub-account, eks cluster, a managed nodegroup for karpenter, karpenter deployment, ingress controllers, LGTM stack, public/private dns zones, cert-manager and a lot more) and I did everything in Terraform, including Kubernetes resources. What I appreciated about creating Kubernetes resources (and helm deployments) in HCL is that it's typed and has a schema, so any ide capable of talking to an LSP (language server protocol - I'm using GNU Emacs with terraform-ls) can provide meaningful auto-completion as well proper syntax checking (I don't need to apply something to see it fail, emacs (via the language server) can already tell me what I'm writing is wrong). I really don't miss having to switch between my ide and the Kubernetes API reference to make sure I'm filling each field correctly.
  • wredcoll 1y ago
    But... so do yaml and json documents?
    • lmm 1y ago
      > so do yaml and json documents? Not really. There are optional ways to add schema but nothing that's established enough to rely on.
      • wredcoll 1y ago
        I mean, I don't want to get into a debate about semantics, but when I open config.json files or kubernetes.yaml files in neovim, i get tab completed fields and values as well as inline errors about unsupported entries. That seems to qualify in my book.
        • lmm 1y ago
          Interesting - but is that because neovim has specifically added support for those formats (i.e. you've got some kind of Kubernetes-specific highlighting, not just generic yaml highlighting code?)
• vanillax 1y ago
  Agree HCL is terrible. K8s YAML is fine. I have yet to hit a use case that cant be solved with its types. If you are doing too much perhaps a config map is the wrong choice.
  • ofrzeta 1y ago
    It's just easier to shoot yourself in the foot with no proper type support (or enforcement) in YAML. I've seen Kubernetes updates fail when the version field was set to 1.30 and it got interpreted as a float 1.3. Sure, someone made a mistakes but the config language should/could stop you from making them.
    • XorNot 1y ago
      Yeah but that's on the application schema. If it's version string why are accepting floats for it?
    • ikiris 1y ago
      so use json?
      • Too 1y ago
        It allows the exact same problem. version: 1.30 vs version: "1.30".
        • Sayrus 1y ago
          Helm supports typing the values passed to the Chart but most charts aren't providing it. Most fields within out-of-the-box Kubernetes resources are using well-defined typed. As much as Helm is prone to some type of errors, it will validate the schema before doing an install or upgrade so `version: 1.30` won't apply but `version: "1.30"` will.
• dochne 1y ago
  My main beef with HCL is a hatred for how it implemented for loops. Absolutely loathsome syntax IMO
  • mdaniel 1y ago
    It was mentioned pretty deep in another thread, but this is just straight up user hostile variable "my_list" { default = ["a", "b"] } resource whatever something { for_each = var.my_list } The given "for_each" argument value is unsuitable: the "for_each" argument must be a map, or set of strings, and you have provided a value of type tuple.
    • Spivak 1y ago
      This is what you get if you want a declarative syntax. HCL doesn't have any concept of a for loop, and can't have any concept of a for loop— it's a data serialization format. Terraform can be transformed to and from JSON losslessly. The looping feature is implemented in Terraform. Ansible's with_items: and loop: do the exact same thing with YAML.
      • garethrowlands 1y ago
        Declarative languages can absolutely loop. Otherwise functional languages wouldn't be a thing. HCL's looping and conditionals are a mess but they're wonderful in comparison to its facilities for defining and calling functions.
        • ziggure 1y ago
          The concept of repeated operations executing with respect to some condition is always going to be a bit different in declarative / functional constructs than in imperative ones. A purely functional language is never going to have the equivalent of: for (...) a++; Good functional languages like Clojure make something like this awkward and painful to do, because it doesn't really make sense in a functional context.
      • mdaniel 1y ago
• acdha 1y ago
  > Developers find HCL very confusing. It can be hard to read. Does it support imports now? Errors can be confusing to debug. This sounds a lot more like “I resented learning something new” than anything about HCL, or possibly confusing learning HCL simultaneously with something complex as a problem with the config language rather than the problem domain being configured.
  • aduwah 1y ago
    Issue is that you do not want a dev learning hcl. Same as you don't want your SRE team learning next and react out of necessity. The ideal solution would be to have an abstraction that is easy to use and does not require learning a whole new concept (especially an ugly one as hcl). Also learning hcl is simply just the tip of the iceberg, with sinking into the dependencies between components and outputs read from a bunch of workspaces etc. It is simply wasted time to have the devs keeping up with all the terraform heap that SREs manage and keep evolving under the hood. The same dev time better spent creating features.
    • acdha 1y ago
      Why? If they can’t learn HCL, they’re not going to be a successful developer. If your argument is instead that they shouldn’t learn infrastructure, then the point is moot because that applies equally to every choice (knowing how to indent YAML doesn’t mean they know what to write). That’s also wrong as an absolute position but for different reasons.
      • aduwah 1y ago
        You don't see my point. The ideal solution would be something that can be learned easily by both the dev and infra side without having to boil the ocean on one side or the other. Something like protobuf was mentioned above which is a better idea than hcl imho
        • acdha 1y ago
          I understand but do not agree with your point. I think two things are being conflated: the difficulty of learning HCL itself and the domain complexity of what almost everyone is learning HCL to do. I’ve seen people bounce off of Terraform and make lengthy rants about how HCL is hard, write thousands of lines of code in their preferred Real Programming Language™, and only eventually realize that the problem was that they thought they were learning one thing (IaC) but were actually learning two things at the same time (IaC and AWS/GCP/etc.) without taking time to formalize their understanding of both. I have no objections to protobufs, but I think that once you’re past a basic level of improvements over YAML (real typing, no magic, good validation and non-corrupting formatters) this matters less than managing the domain complexity. YAML is a bad choice for anything but text documents read by humans because it requires you to know how its magic works to avoid correct inputs producing unexpected outputs (Norway, string/float confusion, punctuation in string values, etc.) and every tool has to invent conventions for templating, flow control, etc. I think HCL is better across the board but am not dogmatic about it - I just want to avoid spending more time out of people’s lives where they realize that they just spent two hours chasing an extra space or not quoting the one value in a list which absolutely must be quoted to avoid misinterpretation.
• programd 1y ago
  Let me throw this out as a provocative take: In the age of AI arguments about a configuration language are moot. Nobody is going to hand craft those deployment configs anymore. The AIs can generate whatever weird syntax the underlying K8s machinery needs and do it more reliably than any human. If not today then probably in 3 months or something. If you want to dream big for K8s 2.0 let AI parse human intent to generate the deployments and the cluster admin. Call it vibe-config or something. Describe what you want in plain language. A good model will think about the edge cases and ask you some questions to clarify, then generate a config for your review. Or apply it automatically if you're an edgelord ops operator. Let's face it, modern code generation is already heading mostly in that direction. You're interacting with an AI to create whatever application you have in your imagination. You still have to guide it to not make stupid choices, but you're not going to hand craft every function. Tell the AI "I want 4 pods with anti-affinity, rolling deployment, connected to the existing Postgres pod and autoscaling based on CPU usage. Think hard about any edge cases I missed." and get on with your life. That's where we're heading. I'm emotionally prepared for the roasting this comment will elicit so go for it. I genuinely want to hear pro and con arguments on this.
  • lmm 1y ago
    All the more reason you need a concise, strict representation of your actual config. If you're trusting an AI to translate fuzzy human intention into a machine protocol, there's less need for fuzzy human affordances in that machine protocol, and you should use one that plays to the strengths of a machine representation - one that's canonical and unambiguous.
  • eddythompson80 1y ago
    If you want to dream big, why not give that post to AI and let it parse it to generate K8s 2.0, then you can get it to generate the application first, then the deployment. You can even have it feature-ask itself in a continuous loop.
• zoobab 1y ago
  Please not HCL. I have headaches from using HCL for Terraform.
• s-zeng 1y ago
  Obligatory mentions of cuelang and dhall here. I've used both for kubernetes and other large configs in multiple software teams and both are significantly more of a joy to work with than HCL or yaml
  • codethief 1y ago
    > Obligatory mentions of cuelang and dhall here. I've used both for kubernetes Could you elaborate on your setup? Do you just convert them to JSON/YAML before passing them to kube/helm or…? (Are you able to type-constrain your values.dhall?)