He's spot on about separating "configuration generation" from convergence. There is no reason for the two to be the same system, the same tool. As he says, Kubernetes is only concerned with the latter, whereas Puppet, Chef, and Terraform conflate the two (insofar as it uses HCL).
And for all the talk of "declarative", there is no reason why the configuration generation stage cannot be imperative, a la Pulumi. It is the desired end state - the catalog that's being generated - that is declarative.
I mostly agree, with the caveat that in my experience, if the configuration generation stage is entirely imperative it is harder to reason about it. That might not be a problem for low-complexity setups, but can get quite important (and bad) in some more involved cases.
My experience too. I strongly believe there is room for some kind of tool to help with this process, whether it be a library, DSL, or framework. Something lightweight that places some order on the problem of generating configuration, nothing more.
Otherwise writing raw python and dumping to JSON (or using python client libraries for whatever you're targeting, e.g. kubernetes), quickly becomes an unmaintainable mess.
Yes, agreed. I don't think Nix nor Guix are there yet, in terms of usability (not that most current alternatives are much better, mind). But I could see a wrapping layer on top of either of them working quite well. It's difficult to come up with abstractions for the kind of complexities we're dealing with nowadays. I'm hopeful someone will eventually, though...
And for all the talk of "declarative", there is no reason why the configuration generation stage cannot be imperative, a la Pulumi. It is the desired end state - the catalog that's being generated - that is declarative.