terraform-provider-aws
terraform-provider-aws copied to clipboard
aws_imagebuilder_component forcing replacement when data changes
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
Terraform CLI and Terraform AWS Provider Version
- Terraform CLI version 0.15.0
- AWS Provider version 4.23.0
Affected Resource(s)
- aws_imagebuilder_component
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
resource "aws_image_builder_component" "this" {
name = var.component_name
version = var.semantic_versioning
platform = var.platform
data = yamlencode(var.data)
}
Debug Output
Panic Output
Expected Behavior
When changing the version
and also data
, terraform should create a new version of the component instead of forcing its replacement, removing it.
AWS CLI Behavior
If you have the same version
and data
, AWS CLI it bring us the error ResourceAlreadyExistsException
.
If you have the same version
with a different data
, AWS CLI it bring us the error ResourceAlreadyExistsException
.
If you have the same data
with a different version
, AWS CLI creates a new version.
If you have the new data
and version
values, AWS CLI creates a new version.
Actual Behavior
When changing both data
and version
to new values, Terraform destroys the previous version and creates a new one.
Steps to Reproduce
- Specify
name
,version
,platform
, anddata
. -
terraform apply
will create the resource with informed version. - Change both
version
anddata
to new values. -
terraform apply
will destroy existing version, and then, will create the resource with new informed version and data.
Important Factoids
References
- #0000
Hello folks, any help on that? It is impact us.
The problem is that the aws_image_builder_component
resource actually references a component version (e.g. ARN: arn:aws:imagebuilder:us-west-2:123456789012:component/examplecomponent/1.2.3/1
).
Looking at how it's handled in other versioned resources (aws_ecs_task_definition
, aws_lambda_layer_version
), the issue could be solved by introducing a skip_destroy
argument. Setting it to true
would make the provider behave exactly as the CLI does - creating a new version would make the provider retain the old version.
An important point is that after updating the component, it'll be pointing to the newest version and therefore all other resources depending on it (e.g. image or container recipes) will automatically switch to this version causing a replacement of them (unless we also add skip_destroy
argument to them).
https://github.com/hashicorp/terraform-provider-aws/pull/22269 https://github.com/hashicorp/terraform-provider-aws/pull/11997
@ricardosouzamorais What do you think?
The skip_destroy
does not exist right now.
What we have done was to ignore the component replacement, incrementing the version number, ALWAYS, and making the recipe pointing to x.x.x
version.
The bug is still in place.
Yes, it does not exist. I wanted to know if that could solve your problem.
Hello @justinretzolk , would you have any news on that?
Thanks a ton.
Hey @ricardosouzamorais 👋 Thank you for checking in on this. Unfortunately, I'm not able to provide an estimate on when this will be looked into due to the potential of shifting priorities (we prioritize work by count of ":+1:" reactions, as well as a few other things). For more information on how we prioritize, check out out prioritization guide.
That said, I'm also curious about Kamil's question above; would a skip_destroy
argument (similar to how aws_ecs_task_definition
and aws_lambda_layer_version
work) work for your use case?
Hey @justinretzolk , in case the object has this attribute I would handle multiple versions of component the same way we do for task definitions?
If so, it makes sense to help.
This functionality has been released in v4.51.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!
@ricardosouzamorais, just a question about this, if you have a component 0.0.1 and you upgrade it to 0.0.2 and use skip_destroy
. Then both will exist, but will 0.0.1 still be managed by TF in some way?
I'm just really struggling with the setup in TF.
I was thinking to use some separate TF stack (with own state) for my components. Then I want to use them inside multiple non-prod and a prod image builder pipelines. The difficulty here is that I have to import the state of my components inside my image builder stack to reference the component:
component {
component_arn = data.terraform_remote_state.components.outputs.random_component_arn
}
But this way I can't "update" the component since it's state is used in a different TF stack. I don't want to create a separate component resource in TF each time. Bundling my components and pipelines in one stack will solve this, but then I end up with non-prod and prod components. Then I won't "reuse" the tested component.
Any "AWS" recommendation here? Maybe I should avoid a "non-prod" image builder pipeline in some way.. because now I have to rebuild the AMI in prod instead of some sort of promotion... Otherwise it's a requirement to have a non-prod and prod environment..
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.