Metadata Data Source: trigger

[cemo]

I am using aws_ami to find right ami in my region. But I am afraid of its changes. I would like to create a freezed data source to protect myself from updates which can cause recreation of instances. Recreating instances is pretty much dangerous since it can simply destroy our cluster. I would like to freeze/fix data sources after fetching its data once. I think that a metadata like trigger might be useful which is similar in null_resource.

# Find the latest available AMI that is tagged with Component = web
data "aws_ami" "web" {
  filter {
    name   = "state"
    values = ["available"]
  }

  filter {
    name   = "tag:Component"
    values = ["web"]
  }

  most_recent = true
}

What do you think? Also what is the current way to be immune for changes in datasources?

[jbardin]

Hi @cemo,

The usual solution to this problem is to use ignore_changes in a lifecycle block to prevent a change to the referenced ami from recreating the instance.

Let me know if that doesn't work for you, or if I'm missing part of this feature request.

[cemo]

@jbardin Thanks, it will work. But what about having trigger part in data_null_resource as in null_resource. I think that it will be a nice addition. What do you think?

[jbardin]

@cemo, I'm not sure what triggers in null_data_source would do exactly, since data sources are always refreshed and only supply data for other resources. Can you give an example configuration that would make use of this?

[cemo]

I considered this approach. This might be valid of all datasource but for the sake of simplicity this can be limited to null_data_source.

data "null_data_source" "test" {
  
  inputs {
    test = "${uuid()}"
  }

  triggers {
    test = "no-trigger"
  }
  
}

I am expect a constant value from null_data_source in this case to set once even if the uuid() is changing. What do you think?
Also /cc @apparentlymart

[apparentlymart]

@cemo I'm afraid I don't understand what behavior you'd expect for that. Would you mind elaborating a little more?

It sounds like you're looking for a way to prevent a data resource from getting refreshed unless some value changes. If so, that would be a core change rather than something we can implement within a single data source, since the data resource lifecycle is fundamental.

This reminds me a little of #11418, although that is about resources being replaced on arbitrary changes. I did a little thought experiment about a similar feature to control refreshing of data sources, but discovered a snag: data source refresh happens before the planning/diffing phase, so it's too early to do any sort of conditional work there.

So I agree with @jbardin that ignore_changes is the right solution here for the moment. It moves the decision into the resource itself, which plays better with Terraform's overall lifecycle (can be dealt with during the plan/diff phase) and also keeps the solution close to the problem: if your goal is "don't recreate this instance when the AMI changes" then it makes sense to me for this to be specified on "this instance", rather than on the AMI.

I think if we were to also implement something like #11418 that would complete the picture here: you'd be able to disable the default behavior of rebuilding whenever the AMI changes, but you'd also be able to specify some other trigger to make it happen, so that you can use some different mechanism to decide if replacing the instance is desirable.

[cemo]

You have the idea what I have in my mind. I am trying to create a constant datasource which is immune to changes. But I am not trying to block refresh lifecycle. I just try to manipulate output of it by looking triggers. It can again refresh itself.

triggers = evaluateNewTriggers();
if(triggers == null || oldTriggers!=triggers){
      value = calculateNewValue()    
}
return value;

I was considering something like this :)

BTW I implemented as you suggested. It seems far more better to me. 👍

[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.