aws_imagebuilder_component forcing replacement when data changes

[ricardo-aspira]

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

1. Specify name, version, platform, and data.
2. terraform apply will create the resource with informed version.
3. Change both version and data to new values.
4. terraform apply will destroy existing version, and then, will create the resource with new informed version and data.

Important Factoids

References

• #0000

[ricardo-aspira]

Hello folks, any help on that?
It is impact us.

[kamilturek]

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).

#22269
#11997

@ricardosouzamorais What do you think?

[ricardo-aspira]

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.

[kamilturek]

Yes, it does not exist. I wanted to know if that could solve your problem.

[ricardo-aspira]

Hello @justinretzolk , would you have any news on that?

Thanks a ton.

[justinretzolk]

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?

[ricardo-aspira]

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.

[github-actions]

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!

[lvthillo]

@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..

[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.