feature: support aws_vpc_ipam cascade for easier deletes

[drewmullen]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

AWS IPAM released a new argument cascade which works like a force_delete. Add argument to the resource schema

Default should be false

New or Affected Resource(s)

• aws_vpc_ipam

Potential Terraform Configuration

resource "aws_vpc_ipam" "test" {
  operating_region {
    region_name = "us-east-1"
  }
  cascade = true
}

References

• https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteIpam.html

[gmichelo]

Anybody working on this?

[drewmullen]

@BigMikes not me! At least not for a couple weeks based on priority

[AurelienNober]

Hello @drewmullen ,
I wanted to have a first look at the internals and thought that this feature could be a good way to do that. Just fyi I use the aws provider on a weekly basis and not for IPAM.
I locally added the cascade option and made it work but I had a few thoughts about the use case. If everything is defined within terraform state, the option is quite useless because all the vpc_ipam dependencies will be destroyed before the vpc_ipam is itself destroyed. Then the main use case for the cascade option would be to ensure resources created outside of terraform are destroyed too. Am I correct? If yes then for the acceptance test, does calling the create ipam scope api directly (to make sure there is a scope created outside of terraform state) sound like a good idea?

[drewmullen]

@AurelienNober

If everything is defined within terraform state, the option is quite useless because all the vpc_ipam dependencies will be destroyed before the vpc_ipam is itself destroyed. Then the main use case for the cascade option would be to ensure resources created outside of terraform are destroyed too

You're 100% correct. The option has very low use-case. In fact, I would personally use the cli command instead if i wanted to use cascade. I considered not opening the issue but ended up opening it because it is a feature of the API and there is a usecase, just a small one.

does calling the create ipam scope api directly (to make sure there is a scope created outside of terraform state) sound like a good idea

No if the feature is included in the provider then it should mimic the API behaviors. Scopes are not the only resource that can be a blocker to deleting: pools, provisioned CIDRs in those pools, or allocations to VPCs can also be a hinder an IPAM deletion.

[AurelienNober]

Thanks for you reply!

No if the feature is included in the provider then it should mimic the API behaviors. Scopes are not the only resource that can be a blocker to deleting: pools, provisioned CIDRs in those pools, or allocations to VPCs can also be a hinder an IPAM deletion.

Ok if I understand correctly, for the acceptance test, creating a scope by api (to create a potential deletion blocker) is ok but not enough as all blockers should be part of the test.

[drewmullen]

Oh, i'm sorry I misunderstood! Yes an extra scope is a perfectly valid test of the functionality! You should only need to test 1 type so Scope is valid

[AurelienNober]

Thanks for your input, tried to do something consistent

[github-actions]

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.