Create only properties?

Terraform Providers Plugin Development
1

Is there a way to define a property that is only used at creation time, but ignored for updates?

  1. I tried a diffsupressfunc that always returns true, but that suppresses the property even at creation time.
  2. I was going to try a custom diff func, but I cannot clear out a diff of a property unless it is a Computed value, which this is not since the user needs to set it at creation time.
  3. I tried enhancing my diffsuppressfunc by checking if d.IsResourceNew() to only suppress if not new, but to my surprise, d.IsResourceNew returns false even during creation.
  4. I tried setting both Computed and Optional as true which kind of works, but when the user changes the value, it still generates a diff which I want to ignore
2

Hello!

Have you tried the following? It’s similar to your first attempt but registers a diff at creation time.

DiffSuppressFunc: func(k, old, new string, d *schema.ResourceData) bool {
    // checks if the old/new values are nil, if they're both nil, then no state exist, so register a diff
    if old == "" && new == "" {
        return false
    }
    return true
},
3

I’m interested in the use case in which a property should be set at create time and have its changes ignored. Normally you’d want to use something like ForceNew, forcing re-creation when the create-time-only field changes. Otherwise, the configuration isn’t really being captured as a code, as a terraform destroy followed by a terraform apply won’t yield the same result.

I think you could set it to optional and computed, and then error out in the CustomizeDiff function if it’s not set at Create time, simulating Required. And the CustomizeDiff could suppress the diff as you indicated.

4

I recently ran across this scenario. The API provides certain input parameters on Create, but offers no corresponding values in the read API. Thus, state cannot be reconciled as there is no way to know what it is. Thus, this property was “create only, ignored for all time afterwards”.

I solved the problem by getting API team to enhance the Read operation, which was its own headache on the calendar :frowning:

5

Yeah, that’s a pattern I’m familiar with, but it seems different than what OP is talking about, I think? I read OP more as “I want to not update even if the config changes”, but I’m struggling to think of why that’s a thing people would want to do.