EMR configurations field forcing new EMR cluster when path changes

[hashibot]

This issue was originally opened by @cpower as hashicorp/terraform#12047. It was migrated here as part of the provider split. The original body of the issue is below.

---

Hi there,

Running terraform apply on a Terraform managed EMR cluster that uses a path.module reference to configurations.json with remote state, when the path to the file changes, causes Terraform to destroy the EMR cluster and create a new one because the path to the configurations.json file is stored in the Terraform state which forces a new resource.

Terraform Version

Terraform v0.8.5

Affected Resource(s)

• aws_emr_cluster

Terraform Configuration Files

resource "aws_emr_cluster" "emr" {
  name = "${var.cluster_name}"
  release_label = "${var.release_label}"
  applications  = ["${split(",",var.applications)}"]
  service_role  = "${var.service_role}"
  log_uri  = "s3n://${var.s3_bucket}"
  master_instance_type = "${var.master_instance_type}"
  core_instance_type   = "${var.core_instance_type}"
  core_instance_count  = "${var.core_instance_count}"
  ec2_attributes {
    key_name = "${var.ec2_key_name}"
    subnet_id = "${data.aws_subnet.subnet.id}"
    instance_profile = "${var.ec2_instance_profile}"
    service_access_security_group = "${var.security_groups["emr_service_access"]}"
    emr_managed_master_security_group = "${var.security_groups["emr_managed_master"]}"
    emr_managed_slave_security_group  = "${var.security_groups["emr_managed_slave"]}"
    additional_master_security_groups = "${var.security_groups["emr_additional_master"]}"
    additional_slave_security_groups  = "${var.security_groups["emr_additional_slave"]}"
  }
  configurations = "${path.module}/${var.configurations}"
}

Expected Behavior

Updating a Terraform managed EMR cluster that uses a path.module reference to a configurations JSON file from a different path/machine when using remote state should not create and destroy a new EMR cluster.

Actual Behavior

Running terraform apply on a Terraform managed EMR cluster that uses a path.module reference, causes Terraform to destroy the EMR cluster and create a new one because the path to the configurations.json file is stored in the Terraform state.

Steps to Reproduce

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

1. terraform apply to create an EMR cluster on MachineA that has a path.module reference to a configurations.json file (use remote state)
2. Move to MachineB or simply change the path to the Terraform code
3. Make no other changes and runterraform apply, Terraform should destroy the EMR cluster and create a new one

References

Related Issues
hashicorp/terraform#8754
hashicorp/terraform#7927

[ghost]

I'm seeing a similar issue without specifying a configurations parameter using Terraform v0.9.11.

This example causes a destroy on every terraform apply

resource "aws_emr_cluster" "emr-cluster" {
  name          = "${length(var.name) > 0 ? var.name : var.tags["environment"]}-emr-cluster"
  release_label = "${var.release_label}"
  applications  = "${split(",",var.applications)}"

  termination_protection = "${var.termination_protection}"
  keep_job_flow_alive_when_no_steps = "${var.keep_job_flow_alive_when_no_steps}"

  ec2_attributes {
    key_name                          = "${var.key_name}"
    subnet_id                         = "${element(split(",", var.private_subnets), count.index)}"
    additional_master_security_groups = "${aws_security_group.emr-cluster-master.id}"
    additional_slave_security_groups  = "${aws_security_group.emr-cluster-slaves.id}"
    instance_profile                  = "${var.use_default_aws_instance_profile == true ? format("arn:aws:iam::%s:instance-profile/%s",var.aws_account_id,var.default_aws_instance_profile) : aws_iam_instance_profile.emr-profile.arn}"
  }


  master_instance_type = "${var.master_instance_type}"
  core_instance_type   = "${var.core_instance_type}"
  core_instance_count  = "${var.core_instance_count}"

  log_uri              = "${module.s3.site_name}/logs"
  visible_to_all_users = "${var.visible_to_all_users}"

  tags = "${var.tags}"

  service_role = "${var.use_default_aws_role == true ? format("arn:aws:iam::%s:role/%s",var.aws_account_id,var.default_aws_role) : aws_iam_role.iam_emr_service_role.arn}"
}

[ghost]

@cpower ☝️

[ghost]

Turns out my issue was related to the log_uri not having a trailing /. I added it and it stopped destroying it.

[bflad]

This relates to #1385 and will likely require creating a new attribute that accepts JSON input instead of a file path/URL (deprecating the existing one) to fix it.

[bflad]

In the meantime, a less than ideal workaround for this particular case can be done using the lifecycle ignore_changes configuration which will allow the file to be in two different paths across workstations or move the file path/URL without resource recreation:

resource "aws_emr_cluster" "example" {
  # ... other configuration ...
  lifecycle {
    ignore_changes = ["configurations"]
  }
}

[bflad]

Version 1.30.0 of the AWS provider, releasing later today, will have a new configurations_json argument that accepts the actual JSON contents and can correctly determine drift from the EMR API. In an upcoming release we'll mark the existing configurations argument as deprecated.

To convert to the new attribute, given this Terraform configuration:

resource "aws_emr_cluster" "example" {
  # ... other configuration ...
  configurations = "example.json"
}

Update it to:

resource "aws_emr_cluster" "example" {
  # ... other configuration ...
  configurations_json = "${file("example.json")}"
}

[bflad]

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

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