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

Updating a file pointed to in aws_emr_cluster.configurations should trigger instance recreation #1385

Closed
synhershko opened this issue Aug 10, 2017 · 5 comments · Fixed by #5191
Labels
bug Addresses a defect in current functionality. service/emr Issues and PRs that pertain to the emr service.
Milestone

Comments

@synhershko
Copy link

synhershko commented Aug 10, 2017

E.g.

resource "aws_emr_cluster" "querying" {
  name          = "Querying"
  release_label = "emr-5.7.0"
  applications  = ["Hadoop", "Hive", "Presto", "Ganglia"]

  configurations = "querying-emr-configurations.json"

  master_instance_type = "m4.large"
  core_instance_type   = "m4.2xlarge"
  core_instance_count  = 2
}

Updating the file querying-emr-configurations.json isn't detected and doesn't trigger new instance creation while it should.

Using v0.10.0

@radeksimko radeksimko added the bug Addresses a defect in current functionality. label Aug 11, 2017
@radeksimko radeksimko added the service/emr Issues and PRs that pertain to the emr service. label Jan 28, 2018
@bflad
Copy link
Contributor

bflad commented May 9, 2018

The configurations attribute is quite an odd implementation in this older resource. Its taking in a file path/URL as an input while the API only ever would know how to return the JSON content. There are two issues here:

  • During the resource read function, this attribute is never getting set into the Terraform state properly (the d.Set() call for it will always fail with trying to write the wrong []*emr.Configuration type as schema.TypeString)
  • Even if we fix the above, we cannot detect drift between the original input (a file path or URL) and what the API returns (JSON content)

It seems like the configurations attribute needs to be deprecated and a new attribute (configurations_json?) created that properly only accepts JSON input so it can be properly compared to what the API returns.

@bflad
Copy link
Contributor

bflad commented May 9, 2018

Related: #543, which would also be fixed with JSON <-> JSON attribute (as it wouldn't matter where the content was coming from to Terraform).

@bflad
Copy link
Contributor

bflad commented Aug 1, 2018

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
Copy link
Contributor

bflad commented Aug 2, 2018

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
Copy link

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

@ghost ghost locked and limited conversation to collaborators Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/emr Issues and PRs that pertain to the emr service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants