[jhoelzel]

While i rally appreciate the effort and am astounded that they already have the pledge of 10 Full time engineers for 5 years I am left wondering 2 things:

A) This could easily be a another reddit moment, where corps and actual bill payers will forget about it in two weeks since it simply -does not concern them-. The supporting list mostly consists of actual competitors.

B) If they can manage all these resources, why can we just simply not do something new along the way? Terraform has its flaws and everyone that seriously had to worked with it can name many.

For instance: Did you know that you cant easily shut down a server when deleting a terraform resource? At least not without hacks or workarounds?

Its time for a "cloud-init native" solution to all these problems and while appreciating the effort i think this fork will actually hinder future development by having things remain the same.

- Cluster Api all the way -

[fishnchips]

> why can we just simply not do something new along the way

Marcin here, one of the member of the OpenTF.

99% of the value of Terraform is its ecosystem - providers, modules, tutorials, courses etc., and millions of lines of battle-tested production code already written in that language. 1% of the value is in the tool itself, with the tool serving as the gatekeeper to all these riches. One of the things that I personally want to see is opening up the codebase to allow building new things on top of it, which then don't need to reinvent the wheel.

You dislike HCL? Fine, have something else give the tool an AST and we'll take it from here. You don't need/want to go through the CLI? Not a problem, embed some of these libraries directly in your app.

[skywhopper]

Not sure what you mean exactly about "shutting down a server when deleting a Terraform resource". But do you think that's something inherent to the design that OpenTF wouldn't be able to address?

Personally I think Terraform hit on a really good pattern for IaC, and while there are lots of rough edges that could be polished, the overall approach is by far the best fit yet invented for the problem it's aiming to solve.

[thayne]

I'm not sure what they mean by that. But one case where terraform's model doesn't work very well, is updating a certificate on a load balancer (to be concrete, say an ACM certificate attached to an NLB in AWS) to a new cert and remove the old one. The proper way to do that, without service interruption is the following:

1. Create new certificate

2. Update the certificate attached to the load balancer

3. Delete old certificate

But it isn't actually possible to do that in that order with terraform because of how dependencies work.

By default what terraform will try to do is:

1. Delete old certificate. this will either fail, because the certificate is in use (as is the case in AWS) or destroy a resource that is still in use and cause the load balancer to enter a bad state

2. Create new certificate

3. Update the load balancer

The only ways I have found to work around this is with targeted applies (which are discouraged), or splitting the change up into multiple code changes, with separate applies for each change.