the idea here is to have (simple, this is lisp after all) code generators that take that DSL and output real terraform, and conversely use oak/tree-sitter to extract said DSL back out from the real terraform.
Using graph unification (see cuelang), we can apply validation on both the LLM output, and the real terraform, and unify / diff3 things from both sides.
The concise DSL allows us to prompt the LLM to do refactors without getting bogged down in syntax (which leads to hallucinations).
@hazelweakly I don't really know anything about terraform / devops (I struggle real bad), I'd be quite interested in hearing your takes, especially if you looked at the plethora of config scaffolding things out there. cue lang/hof is the one that actually makes sense to me, although I didn't look at say, dhall.
@mnl One thing that's really tricky about terraform that isn't obvious is that it's a mapping of JSON to API calls and it's essentially a DAG of RPC calls, combined with a state reconciliation pattern, that maps out a "minimal" set of CRUD operations to achieve a desired state from a given state.
However, the state is theoretically opaque and "should" be transparent. In practice, this isn't true, and the structure of the terraform code (+ symbol names) map to state in a very not obvious way
@mnl that all said, much like most other "DAG" APIs, there's a large bias towards wanting to treat everything as a forest of trees (or a set of call stacks, if you like).
There's also a lot of syntax and complexity around representing optional information, merging default data, handling groups of objects, and providing the ability to represent abstractions.
Terraform does all of those somewhat poorly, as can be seen by the state of the AWS community modules. Holy complexity batman 💀
@mnl as far as what that means for "real challenges", here's a short list of things that are nearly impossible to automate, everyone runs into them, and nobody has good ways to avoid it because it's too complex to "start off" with these patterns:
going from 1 to many (resource, env, region, AZ, etc)
@mnl none of the existing stuff out there really solves any of that imo. What the config lang stuff seems to have (value wise) is making it easier to write reams of boilerplate from a simple config that can be type checked. And yeah, while it's valuable to be able to have a deploy.yml file with
Add comment