aws_elasticsearch_domain apply changes the resource on every execution

[caquino]

Hi there,

Elasticsearch domain keeps being changed on every terraform run.

Terraform Version

Terraform v0.7.0-dev (a445731+CHANGES)

Affected Resource(s)

• aws_elasticsearch_domain

Terraform Configuration Files

resource "aws_elasticsearch_domain" "main" {
  domain_name = "test"
  advanced_options {
    "rest.action.multi.allow_explicit_index" = true
    "indices.fielddata.cache.size" = 40
  }

  ebs_options {
    ebs_enabled = true
    volume_size = 20
    volume_type = "gp2"
  }

  cluster_config {
    instance_type = "m3.medium.elasticsearch"
    instance_count = 4
    zone_awareness_enabled = true
  }

  snapshot_options {
    automated_snapshot_start_hour = 23
  }

  tags {
    Domain      = "test"
  }

  access_policies = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "es:*",
      "Principal": "*",
      "Effect": "Allow",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.168.0.0/24"
          ]
        }
      }
    }
  ]
}
EOF
}

Debug Output

As terraform does not crash does not appear to be relevant, but it can be sent upon request.

Panic Output

No crash.

Expected Behavior

After the first execution the resource should not be modified unless some parameter change is made.

Actual Behavior

terraform apply finishes without any error:
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the terraform show command.

State path: terraform.tfstate

Then if a terraform plan is executed

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

aws_elasticsearch_domain.main: Refreshing state... (ID: REDACTED)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ aws_elasticsearch_domain.main
access_policies: "{"Statement":[{"Action":"es:","Condition":{"IpAddress":{"aws:SourceIp":"192.168.0.0/24"}},"Effect":"Allow","Principal":"","Resource":"REDACTED:domain/test/"}],"Version":"2012-10-17"}" => "{"Statement":[{"Action":"es:","Condition":{"IpAddress":{"aws:SourceIp":["192.168.0.0/24"]}},"Effec
t":"Allow","Principal":"*"}],"Version":"2012-10-17"}"
advanced_options.rest.action.multi.allow_explicit_index: "false" => "1"

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. terraform plan or terraform apply

Important Factoids

No interesting facts

[jedi4ever]

related , if volume_type is not specified it will try to replace "" => "gp2"

[jedi4ever]

setting the value to "1" in the TF config file will still do a "false" => "1"

[aerickson]

Seems like a dupe of #3634.

[jedi4ever]

@aerickson only partial , #3634 is all about IAM policies which is a general terraform problem.
This issue also highlights a problem with advanced_options

[bnordbo]

I'm not sure this is a Terraform bug: I see the same behaviour – the Resource being removed from the policy on every Terraform run. However, if I edit the policy in the console, the Resource is also added upon saving. Adding that Resource to the Terraform policy seems to make the problem go away. So maybe this is just a case of the documentation being slightly inaccurate?

[apparentlymart]

Hi all,

I was considering closing this in favor of #5067 (which is in turn what #3634 was closed in favor of) but I agree with @jedi4ever that this has a unique part in the advanced_options.rest.action.multi.allow_explicit_index diff.

So let's say that this ticket is for the advanced_options issue, and let #5067 represent the issue with the IAM policy normalization.

---

FWIW, as @bnordbo said the IAM policy issue is well-understood at this point and can be worked around by explicitly adding Resource to the policy. Hopefully now that we have some support for doing general diff normalizations it won't take much more work for #5067 to take care of this issue automatically.

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