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

[Idea] aws_iam_role and aws_iam_role is buddy for destroying #453

Closed
hashibot opened this issue Jun 13, 2017 · 3 comments
Closed

[Idea] aws_iam_role and aws_iam_role is buddy for destroying #453

hashibot opened this issue Jun 13, 2017 · 3 comments
Labels
question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com. service/iam Issues and PRs that pertain to the iam service.

Comments

@hashibot
Copy link

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


Hi there,

If we create a aws_iam_role resource name role, a aws_iam_role_policy named role_policy for the aws_iam_role, another resource name R depends on role and other resources name O depend on R, when destroy them, according the dependency, the role_policy maybe be destroyed first. While destroy the R, need the iam policy to destory O first. Because the R depends on permission of role( yes, it's the role_policy), the role_policy should not be destroyed before destroy role.

We could just add a depends_on the role_policy for the R, but when use the R for using module, we can't do it(currently, we can't use depends_on for using module). Terraform detects the dependency for us, sometimes Terraform destroys the role_policy first.

So, we think the role and role_policy should be buddy for destroying, when destroy one of them, we should confirm that all of them could be destroyed!

Solutions:

  1. add an option: buddy_destroy

  2. add depends_on for using module

I will provide more information after work.

Terraform Version

Terraform v0.8.0

Affected Resource(s)

  • aws_iam_role
  • aws_iam_role_policy
@hashibot hashibot added the question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com. label Jun 13, 2017
@radeksimko radeksimko added the service/iam Issues and PRs that pertain to the iam service. label Jan 25, 2018
@paultyng
Copy link
Contributor

I'm hoping since no additional information was provided here you have worked this out. Without a Terraform config it is hard for us to reproduce this but I have not seen any other similar issues crop up so going to close due to lack of information. If you can provide a config that reproduces this please comment here and I'll be happy to reopen.

@bflad
Copy link
Contributor

bflad commented Jun 21, 2018

This issue was errantly moved to the AWS provider repository during the core/provider split of Terraform 0.10 as well -- it appears to be an upstream Terraform core issue since it relates to dependency ordering or changes to the Terraform provider SDK.

Support for depends_on can between modules can be tracked here: hashicorp/terraform#17101

If Terraform core does ever support having resources internally be grouped together, e.g. all child aws_iam_role_policy to their parent aws_iam_role resource be treated as "one" in the dependency graph when referencing the aws_iam_role, we can reinvestigate this concept.

@ghost
Copy link

ghost commented Apr 5, 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 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question A question about existing functionality; most questions are re-routed to discuss.hashicorp.com. service/iam Issues and PRs that pertain to the iam service.
Projects
None yet
Development

No branches or pull requests

4 participants