[markbaikal]

Isopod is notable for allowing the fetching of remote data that can then be used to configure the kubernetes objects. Terraform and pulumi are the only other ones that allow this. Bad about isopod is that the tool does not appear to automatically delete resources in the cluster after they are deleted from the code, and instead, a delete function must be called manually. That is a conceptual weakness compared to terraform and pulumi, and also a weakness compared to `kubectl apply --prune`.

[zapita]

CUE also allows this in their scripting layer.

https://cuelang.org

https://godoc.org/cuelang.org/go/pkg/tool/http

[dilyevsky]

This is wip. I made some big strides in that direction but wasn’t able to finish it in time.

[markbaikal]

I have great respect for your work. Do you have ideas or plans how to automatically delete objects in the cluster after they were deleted from the code? Terraform and pulumi are notable for maintaining their own state outside of the cloud provider or kubernetes, and this state can go out of sync, but `kubectl apply --prune` should not need that.

[dilyevsky]

Appreciate! Charles had really polished it up too and did all the heavy lifting for open-sourcing this thing so big kudos to him and other Cruisers who contributed!

For deletion I explored a similar approach used in helm3 - use tombstone object (crd) for every deploy and store the state there. Kubernetes objects are simply deleted if they didn’t appear in kube.put in the latest release and for any other state you can use “remove” callback from config itself because full config is stashed in kubernetes for every deploy.