i never found myself struggling with submodules, but at times i found myself just slightly annoyed (especially when having to remove/replace submodules), especially when they are used for simpler use cases.
i actually ended up creating https://carvel.dev/vendir/ for some of the overlapping use cases. aside from not being git specific (for source content or destination), its entirely transparent to consumers of the repo as they do not need to know how some subset of content is being managed. (i am of course a fan of committing vendored content into repos and ignore small price of increasing repo size).
> It would be nice if there was a separate state reconciliation system that one could adapt to use with Cue or Dhall or any other frontend
this exactly was thinking behind https://carvel.dev/kapp for Kubernetes (i'm one of the maintainers). it makes a point to not know how you decided to generate your Kubernetes config -- just takes it as input.
> In particular the ability to import other files as semantic hashes seems like a great feature.
it's an interesting feature but seems like it should be unnecessary given that config can be easily checked into git (your own and its dependencies).
i think kubernetes is not a great example in favor of more client state (like tf) since k8s has uniform resource structure (metadata.*) and first class labeling support. but as you point out kubectl doesnt use labels well (at least imho).
when building https://carvel.dev/kapp (which i think of as "optimized terraform" for k8s) the goal was absolutely to take advantage of those k8s features. we ended up providing two capabilities: direct label (more advanced) and "app name" (more user friendly). from impl standpoint, difference is how much state is maintained.
"kapp deploy -a label:x=y -f ..." allows user to specify label that is applied to all deployed resources and is also used for querying k8s to determine whats out there under given label. invocation is completely stateless since burden of keeping/providing state (in this case the label x=y) is shifted to the user. downside of course is that all apis within k8s need to be iterated over. (side note, fun features like "kapp delete -a label:!x" are free thanks to k8s querying).
"kapp deploy -a my-app -f ..." gives user ability to associate name with uniquely auto-generated label. this case is more stateful than previous but again only label needs to be saved (we use ConfigMap to store that label). if this state is lost, one has to only recover generated label.
imho k8s api structure enables focused tools like kapp to be much much simpler than more generic tool like terraform. as much as i'd like for terraform to keep less state, i totally appreciate its needs to support lowest common denominator feature set.
common discussion topics:
* whats the lowest common denominator for apis that need to be supported
* how much state to store client side vs server side (in the api itself e.g. tags or in "assistive service" e.g. s3 api)
* is it enough to just store resource identifiers vs whole resource content (e.g. can resource content be retrieved at a later point; if content is stored, is it sensitive)
* how easy is it to recover from complete state loss
i would be interested to hear your take on comparison with your current pulumi setup.
i've been somewhat spoiled by using tools above so here are some benefits of using them that might align with some of your points within your article:
ytt:
- start with existing YAML configuration and "upgrade inline" with necessary templating
- fully sandboxed configuration building with a python-like language (no accidental dependencies on time, network, disk, etc. like you would experience with "regular" programming languages)
- ability to use both templating and overlaying to "shape" configuration data quickly and reliably.
kbld:
- adds image references to make deploys more deterministic
kapp:
- deals with ordering of CRDs, namespaces and other resources in one go
- works with resources in bulk (tracks them automatically via labels, prunes them when they are no longer needed etc.)
- waits for common resources to complete deploy
- does not store any state except one configmap with generated label (no complex failure scenarios).
https://get-ytt.io (i am one of the authors), one of the tools that inspired yglu, has been designed from ground up with an eye towards security even though its turing complete.
it is based on starlark which is a runtime that does not have facilities to do networking, fs access, etc. building on that, ytt does not allow/provide any kind of non-deterministic operations (access to time, disk, network, random, etc). it expects user to specify explicitly which files to load via -f flag (ie ytt template cannot load random template from fs).
there are several computation attacks that are currently possible (eg infinite loop) but that could be easily addressed thru global timeout for example.
> I like the idea of having a state and resolving differences between desired and actual state, but not enough to rewrite everything in HCL.
i authored https://get-kapp.io based on my previous experiences managing iaas resources as cattle. it strongly revolves around idea of managing chnageset between actual and desired configuration.
it was also built as a tool that solely focuses on deployment to k8s, leaving configuration building (ie templating) to other tools.
take a look at it, would love to hear what you think.
i actually ended up creating https://carvel.dev/vendir/ for some of the overlapping use cases. aside from not being git specific (for source content or destination), its entirely transparent to consumers of the repo as they do not need to know how some subset of content is being managed. (i am of course a fan of committing vendored content into repos and ignore small price of increasing repo size).