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

ECS service resource always shows difference #2722

Closed
rgabo opened this issue Jul 14, 2015 · 8 comments
Closed

ECS service resource always shows difference #2722

rgabo opened this issue Jul 14, 2015 · 8 comments

Comments

@rgabo
Copy link

rgabo commented Jul 14, 2015

An ECS service defined in Terraform will always include a modify step in the plan because the name of the iam_role and the name of the task_definition:

~ aws_ecs_service.empire
    iam_role:        "arn:aws:iam::002835877877:role/prd-empire" => "prd-empire"
    task_definition: "prd-empire:8" => "prd-empire"

It seems that the revision of the task definition is included in the original name. Terraform should detect a change in the dependent task_definition resource and only modify if necessary.

Also, the fully-qualified iam_role is compared to the short name of the iam_role. This can probably be fixed if the aws_iam_role resource has an arn output attribute.

@rgabo
Copy link
Author

rgabo commented Jul 14, 2015

Changing the iam_role attribute to aws_iam_role.foo.arn gets rid of the iam_role difference, only the task_definition revision difference remains:

~ aws_ecs_service.empire
    task_definition: "prd-empire:8" => "prd-empire"

@radeksimko
Copy link
Member

Thanks for the report. I guess we just need something similar to this:
https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_ecs_service.go#L140-146

TBH I never referenced IAM roles via names, always via ARNs (I did not know it's even possible). It would be worth checking other IAM-related resources and how these handle the same case.

@rgabo
Copy link
Author

rgabo commented Jul 14, 2015

To clarify, the IAM role was referenced by its id property and that has the short name value.

Cool, we can take a stab at the fix and send a PR, I thought it would be straightforward, just wanted to make sure that there was an issue for it.

@pikeas
Copy link
Contributor

pikeas commented Aug 4, 2015

Seeing the opposite problem - I've updated a task definition, which is depended on by an ECS service - task_definition: "${aws_ecs_task_definition.controller.arn}". I'm using the ARN, which includes name + revision. The service should be updated by Terraform, but currently that's not happening.

LMK if I should open a separate issue.

@radeksimko
Copy link
Member

@rgabo Just noticed your other question:

Terraform should detect a change in the dependent task_definition resource and only modify if necessary.

It does detect it, if you use the right attributes. I'm not sure whether you're using id or family, but both are purposely used for uniquely identifying the task definition (even when version is bumped, it stays the same). Therefore none of those are good attributes for referencing. Either try ARN or combination of family + version:

task_definition = "${aws_ecs_task_definition.jenkins.family}:${aws_ecs_task_definition.jenkins.revision}"

@radeksimko
Copy link
Member

@pikeas I think this is tracked in #2694 If not, please open a new issue and attach some Terraform configs so we can reproduce and fix it.

@radeksimko
Copy link
Member

Passing IAM role name into iam_role will be possible when #3061 gets merged.

@ghost
Copy link

ghost commented May 1, 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 May 1, 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

3 participants