Providers: Allow configuration or logic for Creating or Updating

[pearkes]

Sometimes you don't want to update a resource, but would rather have a new one.

An example is DigitalOcean. Sometimes, you just want a new droplet on resize instead of "resizing", or if you're resizing down, DO can't do that so you want it to be recreated.

There is definitely a need for richer logic here.

See also #107.

[mitchellh]

I agree. I think there is room here for some meta-parameter to specify this behavior. Let me think on it.

[mitchellh]

With TF 0.3 we added the lifecycle block to resources. This would be the perfect place to put an option. Example/idea:

resource "server" "foo" {
    ...

    lifecycle {
        update = false
    }
}

[phinze]

AFAICT this is still a valid feature request. I'm interpreting this as a lifecycle parameter that ensures any diff is equivalent to a ForceNew change. Perhaps the lifecycle parameter could be be called immutable = true?

[apparentlymart]

(Ended up finding this just because I was curious as to what is the oldest open issue! 😀)

A lifecycle attribute as discussed in the above examples would get to the original use-case but would be a bit of a blunt instrument: the given use-case is for a specific attribute on a resource, rather than any attribute on that resource.

So perhaps it would be appropriate to have an analog to ignore_changes called force_replace, which takes a list of attributes that will artificially "force new resource" when they change:

resource "digitalocean_droplet" "web" {
  image  = "ubuntu-14-04-x64"
  name   = "web-1"
  region = "nyc2"
  size   = "512mb"

  lifecycle {
    "force_replace" = ["size"]
  }
}

With that said, the motivating example of DigitalOcean requiring a replace only when size gets lower made me think of a similar use-case for Amazon RDS instances that partially motivated my proposal in #8769. Perhaps this resource implementation should just "know" that scaling down requires a new resource, and generate the requisite replace diff by default.

[artburkart]

This was effectively the approach used to implement aws_instance resizing (#11998), right? If so, then maybe it's time to implement something similar for DO?

[afeld]

Short of adding new options, taint can be used for forcing recreation.

[apparentlymart]

The other issue #8769 that I mentioned above has now been completed, so it's possible to use the new CustomizeDiff mechanism within the digitalocean_droplet resource to decide dynamically whether a particular size change requires a new resource:

    old, new := d.GetChange("size")
    if dropletSizeLower(new, old) {
      d.ForceNew("size")
    }

Assuming a suitable implementation of dropletSizeLower, this would cause size to be marked as (forces new resource) when the size decreases, but to update in place if it's the same or increased.

This now allows providers to address the original use-case as stated. It may still be interesting to allow the user to override the behavior of particular attributes within configuration, but since that was not the original use-case presented and we don't seem to have a compelling reason to support it right now I'm going to close this out. If someone does have a use-case where forcing replacement rather than in-place modification is needed (and where running terraform taint isn't suitable) then I'd ask that they open a fresh issue that describes the use-case in more detail so that we can figure out the best way to address it.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.