Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMR configurations field forcing new EMR cluster when path changes #12047

Closed
cpower opened this issue Feb 17, 2017 · 2 comments
Closed

EMR configurations field forcing new EMR cluster when path changes #12047

cpower opened this issue Feb 17, 2017 · 2 comments

Comments

@cpower
Copy link

cpower commented Feb 17, 2017

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
#8754
#7927

@errriclee
Copy link
Contributor

errriclee commented May 24, 2017

According to

if err := readBodyJson(input, &configsOut); err != nil {
you can specify the contents of the file as well, instead of the file path. Using a template_file as the value of configurations will work and not cause unnecessary diff's.

I have tested this with the latest 0.9.5. I did not check which version this first appeared.

@ghost
Copy link

ghost commented Apr 9, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants