Ignore_changes on a set

Good evening,

I’m using the aws_elasticsearch_domain resource and have set a default value for the start_at attribute using timestamp(). Unfortunately this requires ignore_changes to prevent constant drift.

How does one ignore just the start_at attribute since it’s part of the maintenance_schedule block which is a set?

You might have to just try a few things until you find the right syntax. I have done something similar with load balancer listeners.

  lifecycle {
    ignore_changes = [
      maintenance_schedule[0].start_at
    ]

Or maybe this:

  lifecycle {
    ignore_changes = [
      maintenance_schedule.start_at
    ]

I’m presently at auto_tune_options[0].maintenance_schedule, but haven’t been able to get any further.

@apparentlymart, can you tell me what I’m missing?

A set is an unordered collection of values, so you cannot index into it. The only option here is to ignore the changes on the entire set.

That was my fear. Thank you @jbardin .

@Kimmel,

I could probably add that if this is causing an issue which cannot be worked around, it would be good to record the problem directly with the provider. The provider should not be overriding a value set in the configuration, which is arguably a bug in the provider. If the problem is a limitation with the remote API or maybe even the provider SDK, a different data structure should be offered to accommodate the changes.

1 Like

Found Cannot create stable aws_elasticsearch_domain resources with auto_tune_options specified · Issue #22239 · hashicorp/terraform-provider-aws · GitHub laying out the use of a time_static resource to stablize auto_tune_options

I’m now using

resource "time_offset" "start_at" {
  triggers = { create = local.name_tag }
  offset_hours = 4
}
resource "aws_elasticsearch_domain" "es" {
  domain_name = local.name_tag
  auto_tune_options {
    maintenance_schedule {
      start_at = time_offset.start_at.rfc3339
      ...
    }
    ...
  }
  ...
}

Thinking we may want to tie the trigger to variables setting up the cron instead, but this is sufficient for me for now.