4 ms·

In the best case this is true. In the worst case the behavior of a resource in state X differs depending on it having been in state Y, so you have the same prob

by jen20 3y ago

In the best case this is true. In the worst case the behavior of a resource in state X differs depending on it having been in state Y, so you have the same problem.

viraptor 3y ago
But that's not related to the tool anymore. You'll have the same issue regardless how you created that resource. Also, FWIW, I've been dealing with automation of services through Terraform and others for 2 decades or so and never ran into an issue like that. The one that comes closest is AWS certificate which requires either a parallel deployment or the first attempt to fail (if you're using cloudformation stacks anyway). Still - not a serious issue in practice.
- jen20 3y ago
  Glad to know you’ve been dealing with Terraform for longer than the 8th highest contributor. Lots of AWS resources behave this way. Perhaps you’re not doing anything serious enough to run into these conditions?
  - viraptor 3y ago
    I wrote "through Terraform and others", not Terraform only. Instead of trying to gotcha me, do you want to provide some examples where creating a resource and changing an attribute results in something different than creating one with the final attribute values?
    - jen20 3y ago
      EKS clusters is a good one. A cluster starting at Kubernetes 1.28 will be in a wildly different state to one upgraded from Kubernetes 1.17 and upgraded through every version. More has come under management scope since 1.17, but even today the add-on model doesn’t cover lots of important aspects. S3 buckets are another - it’s no longer even possible to create some types of buckets that exist in the wild today, thanks to changes in how canned ACLs may be provisioned. Older buckets have their access rules unchanged however. These are two super common resources in the biggest cloud. I’m sure if I went digging in Azure or GCP I could find dozens of non-trivial cases of this that actually make a difference - database-as-a-service offers are likely a target-rich environment for this.
      - viraptor 3y ago
        That's a different issue than what I thought you're talking about, and I'm not sure why it's relevant here. None of the declarative/imperative systems can deal with future compatibility. The service you're using may change the meaning of some API call/values - there's nothing we can do about it apart from updating the software, whether you're using Terraform or Ansible.

by jen20 3y ago

In the best case this is true. In the worst case the behavior of a resource in state X differs depending on it having been in state Y, so you have the same problem.

viraptor 3y ago

But that's not related to the tool anymore. You'll have the same issue regardless how you created that resource. Also, FWIW, I've been dealing with automation of services through Terraform and others for 2 decades or so and never ran into an issue like that. The one that comes closest is AWS certificate which requires either a parallel deployment or the first attempt to fail (if you're using cloudformation stacks anyway). Still - not a serious issue in practice.

jen20 3y ago
Glad to know you’ve been dealing with Terraform for longer than the 8th highest contributor. Lots of AWS resources behave this way. Perhaps you’re not doing anything serious enough to run into these conditions?
- viraptor 3y ago
  I wrote "through Terraform and others", not Terraform only. Instead of trying to gotcha me, do you want to provide some examples where creating a resource and changing an attribute results in something different than creating one with the final attribute values?
  - jen20 3y ago
    EKS clusters is a good one. A cluster starting at Kubernetes 1.28 will be in a wildly different state to one upgraded from Kubernetes 1.17 and upgraded through every version. More has come under management scope since 1.17, but even today the add-on model doesn’t cover lots of important aspects. S3 buckets are another - it’s no longer even possible to create some types of buckets that exist in the wild today, thanks to changes in how canned ACLs may be provisioned. Older buckets have their access rules unchanged however. These are two super common resources in the biggest cloud. I’m sure if I went digging in Azure or GCP I could find dozens of non-trivial cases of this that actually make a difference - database-as-a-service offers are likely a target-rich environment for this.
    - viraptor 3y ago
      That's a different issue than what I thought you're talking about, and I'm not sure why it's relevant here. None of the declarative/imperative systems can deal with future compatibility. The service you're using may change the meaning of some API call/values - there's nothing we can do about it apart from updating the software, whether you're using Terraform or Ansible.