Terraform-provider-aws: Plan always includes change to aws_elasticsearch_domain after disabling dedicated master manually

[hashibot]

_This issue was originally opened by @looppair as hashicorp/terraform#8682. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

0.7.3

Affected Resource

• aws_elasticsearch_domain
  

  Terraform Configuration Files

resource "aws_elasticsearch_domain" "foo" {
  […]
  cluster_config {
    instance_type = "r3.large.elasticsearch"
    instance_count = "3"
    zone_awareness_enabled = false
    dedicated_master_enabled = false
  }
  […]
}

Steps to Reproduce

1. Set up ElasticSearch on AWS with three dedicated m3.medium.elasticsearch master hosts using Terraform
2. Manually disable dedicated master setting in the cluster node configuration
3. Modify the Terraform configuration to disable dedicated master
4. terraform apply
5. terraform plan
   

   Expected Behavior

terraform plan should report no changes planned after terraform apply.

Actual Behavior

The plan output always includes the following:

~ aws_elasticsearch_domain.loop
    cluster_config.0.dedicated_master_count: "3" => "0"
    cluster_config.0.dedicated_master_type:  "m3.medium.elasticsearch" => ""

[dani-lanaya]

Also getting this issue without specifying a dedicated_master_count or dedicated_master_type. Terraform is reporting that the access_policy is changed, although it's identical in AWS. The update takes up 5-15 minutes on every run, so this is a pretty high priority for me. This is on Terraform v0.10.3

[bflad]

Redirecting duplicate issue #1067 here.

[mbolek]

Hitting this issue on 0.11.7. State file reports

                            "cluster_config.0.dedicated_master_count": "3",
                            "cluster_config.0.dedicated_master_enabled": "false",
                            "cluster_config.0.dedicated_master_type": "m3.large.elasticsearch",

hence:

  ~ module.elasticsearch_logs.aws_elasticsearch_domain.es
      cluster_config.0.dedicated_master_count: "3" => "0"
      cluster_config.0.dedicated_master_type:  "m3.large.elasticsearch" => ""

and aws cli shows (in webUI there is no info on this):

        "ElasticsearchClusterConfig": {
            "DedicatedMasterEnabled": false,
            "InstanceCount": 2,
            "ZoneAwarenessEnabled": true,
            "DedicatedMasterType": "m3.large.elasticsearch",
            "InstanceType": "r4.large.elasticsearch",
            "DedicatedMasterCount": 3
        },

So it would seem that AWS still has masters configured but disabled. It's not 'easily' possible to remove this config from AWS even using cli:

aws es update-elasticsearch-domain-config --domain-name XXX --elasticsearch-cluster-config DedicatedMasterCount=0                       

An error occurred (ValidationException) when calling the UpdateElasticsearchDomainConfig operation: DedicatedMasterEnabled must be set to True to specify the DedicatedMasterCount and DedicatedMasterType option,

I don't want to reenable masters now, but there still seems to be an issue here, since AWS (at least in the UI) doesn't allow to set the master count to 0 and then disable - the only valid options are 3 and 5.
Maybe terraform should not report/try to make changes to masters when"DedicatedMasterEnabled": false, ?

[bflad]

Releasing in version 1.31.0 of the AWS provider, likely later today, the aws_elasticsearch_domain resource will now ignore plan differences for dedicated_master_count and dedicated_master_type when dedicated_master_enabled is disabled. 👍

[bflad]

This has been released in version 1.31.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[mbolek]

Problem fixed, awesome, thanks

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!