Open harryw opened 4 years ago
Hey @harryw π Thank you for taking the time to file this issue! Given that there's been a number of AWS Provider releases since you initially filed it, can you confirm if you're still experiencing this behavior?
I can confirm this error still persists. Basically, renaming a code deploy group triggers this.
# aws_codedeploy_deployment_group.default[0] will be updated in-place
~ resource "aws_codedeploy_deployment_group" "default" {
~ deployment_group_name = "old" -> "new"
Error: Error updating CodeDeploy deployment group: DeploymentGroupDoesNotExistException: No Deployment Group
found for name: new
Terraform v1.0.10
provider registry.terraform.io/hashicorp/aws v3.63.0
I ran into this issue. It appears that the rename does occur, however, and running terraform apply
a second time reports successes.
Community Note
Terraform Version
Terraform v0.12.23
Affected Resource(s)
Terraform Configuration Files
Debug Output
Expected Behavior
When renaming the aws_codedeploy_app resource, the app gets replaced. The aws_codedeploy_deployment_group resource is owned by the app, and so when the app is deleted the deployment group gets deleted also.
The expected behavior is that a replacement of the TF app resource should trigger a replacement of the TF deployment group resource.
Actual Behavior
When the app resource is replaced, TF then tries to modify the dependent deployment group, and this fails because the deployment group no longer exists.
Steps to Reproduce
codedeploy_role_name
variable to an appropriate value. An IAM role is omitted from this example to keep it small and readable.terraform apply
codedeploy_app_name
variable.terraform plan
The plan looks like this:
terraform apply
The apply results in an error like this:
References
I've run into this at the same time as another, very similar, issue related to Lambda functions and their associated aliases. Renaming a function triggers a replacement, deleting an associated alias, but then TF tries to modify the deleted alias. That was reported in #10298. A single-line fix was submitted 3 months ago in #11170 as a draft PR, but it was never progressed to a proper PR. It seems likely that the same kind of fix would address this issue.