ignore_changes for specific nested arguments

[danhart]

I have a cloudfront distribution configuration like so:

resource "aws_cloudfront_distribution" "CodesTable" {
  origin {
    domain_name = "${var.builds_bucket}"
    origin_id   = "s3-builds-bucket"
    origin_path = "/ss-codes/1374"

    custom_origin_config {
      http_port = 80
      https_port = 443
      origin_ssl_protocols = ["TLSv1", "TLSv1.1", "TLSv1.2"]
      origin_protocol_policy = "http-only"
    }
  }

  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods  = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    target_origin_id = "s3-builds-bucket"
    cached_methods = ["GET", "HEAD"]

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "allow-all"
  }

  price_class = "PriceClass_100"

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  lifecycle {
    ignore_changes = ["origin.0.origin_path"]
  }
}

I'm trying to just ignore changes to the first/only origin's origin_path. However ignore_changes = ["origin.0.origin_path"] does not work, and terraform still retains control of this argument. I am successfully able to set ignore_changes = ["origin"], however this ignores the whole of the origin argument and all nested arguments.

Is there a way I can just ignore specifically origin_path? I've looked at these issues:

• Terraform apply wants to change disk.0.disk_sharing every time. terraform-provider-vsphere#290
• ignore_changes should support wildcards #5666

But haven't been able to find a solution that works.

I am running terraform_0.11.3_linux_amd64.

[ghost]

This issue has been automatically migrated to hashicorp/terraform-provider-aws#3819 because it looks like an issue with that provider. If you believe this is not an issue with the provider, please reply to hashicorp/terraform-provider-aws#3819.

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