3 ms·

I’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how d

I’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?

voidfunc 2y ago
You write code to do these things? If there's a requirement for you to be able to do such a thing make it a feature, implement it with tests and voila, no different than any other feature or bug you work on is it?
diggan 2y ago
> For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? let front_id = if instance_exists("front_balancer") { return fetch_instance("front_balancer").id } else { return create_new_instance("front_balancer", front_balancer_opts).id } Or however else you would manage that sort of thing in your favorite programming language. > I need to make a small change, how do I know what parts of my scripts to run? Either just re-run the parts you know you've changed (manually or based on git diffs), or even better, make the entire thing idempotent and you won't have to care, re-run the entire program after each change and it'll automagically work.
- michaelmior 2y ago
  > Either just re-run the parts you know you've changed (manually or based on git diffs) This is exactly the sort of thing Terraform is designed to avoid because it can obviously get quite messy. Agreed that making things idempotent solves that problem, but it's not always obvious/easy how to do so.
- kikimora 2y ago
  I get the idea but I don't think it addresses the issue. There has to be a function that a) checks if instance exists b) checks if instance state is what I want (e.g. it has 8 GB ram) c) if not it updates the instance. Ideally it also locks environment while doing this to prevent race conditions. It can be written but seems to be quite cumbersome. Complexity of this code and also time it takes to run it what concerns me most. I guess this is why terraform state is there. IMHO state is IaaC biggest weakness because you have to keep it consistent with actual cloud state. If we can just query state from the cloud and make it performant + be able to automatically (or just fast enough) select resources to be update it would be ideal.
klooney 2y ago
Here are the things that TF does that you are probably not going to get around to in a comprehensive way- - State tracking, especially all of the tedious per cloud resource details - Parallelism- TF defaults to 10 threads at a time. You won't notice this when you write a demo to deploy one thing, but it really matters as you accrete more things. - Dependency tracking- hand in hand with the parallelism, but this is what makes it possible. It is tedious, resource by resource blood sweat and tears stuff, and enabled by the inexpressive nature of HCL Plus, you know, all of the work that has already done by other people to wrap a million quirky APIs in a uniform way.

voidfunc 2y ago

You write code to do these things? If there's a requirement for you to be able to do such a thing make it a feature, implement it with tests and voila, no different than any other feature or bug you work on is it?

diggan 2y ago

> For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? let front_id = if instance_exists("front_balancer") { return fetch_instance("front_balancer").id } else { return create_new_instance("front_balancer", front_balancer_opts).id } Or however else you would manage that sort of thing in your favorite programming language. > I need to make a small change, how do I know what parts of my scripts to run? Either just re-run the parts you know you've changed (manually or based on git diffs), or even better, make the entire thing idempotent and you won't have to care, re-run the entire program after each change and it'll automagically work.

michaelmior 2y ago
> Either just re-run the parts you know you've changed (manually or based on git diffs) This is exactly the sort of thing Terraform is designed to avoid because it can obviously get quite messy. Agreed that making things idempotent solves that problem, but it's not always obvious/easy how to do so.
kikimora 2y ago
I get the idea but I don't think it addresses the issue. There has to be a function that a) checks if instance exists b) checks if instance state is what I want (e.g. it has 8 GB ram) c) if not it updates the instance. Ideally it also locks environment while doing this to prevent race conditions. It can be written but seems to be quite cumbersome. Complexity of this code and also time it takes to run it what concerns me most. I guess this is why terraform state is there. IMHO state is IaaC biggest weakness because you have to keep it consistent with actual cloud state. If we can just query state from the cloud and make it performant + be able to automatically (or just fast enough) select resources to be update it would be ideal.

klooney 2y ago

Here are the things that TF does that you are probably not going to get around to in a comprehensive way- - State tracking, especially all of the tedious per cloud resource details - Parallelism- TF defaults to 10 threads at a time. You won't notice this when you write a demo to deploy one thing, but it really matters as you accrete more things. - Dependency tracking- hand in hand with the parallelism, but this is what makes it possible. It is tedious, resource by resource blood sweat and tears stuff, and enabled by the inexpressive nature of HCL Plus, you know, all of the work that has already done by other people to wrap a million quirky APIs in a uniform way.