aws_elastic_beanstalk_application_version in terraform conceptual issues?

[jwconway]

Hi,

I'm not really sure if this is a bug but there is definitely an issue in how terraform deals with elasticbeanstalk application versions (aws_elastic_beanstalk_application_version).

TL;DR; if an aws_elastic_beanstalk_application_version resource has its name changed then my question is whether the existing application version should be updated or a new one created?

I attempted to manage my application versions in my terraform template by parameterising the name. This was an attempt to have a new application version created by our CI process whenever the contents of the application changed. This way in elasticbeanstalk i could keep a list of historic application versions so that i could roll back etc. This didnt work as the same application version was constantly updated and in effect i lost the history of all application versions.

I then tried to parameterise the logical resource reference name, but this isnt supported by terraform.

Currently my solution is to manage my application versions outside of terraform which is disappointing as there are other associated resources such as the S3 bucket and permissions to worry about.

It seems that the aws_elastic_beanstalk_application_version in terraform isnt useful at all as I assume keeping application version history is a common approach when using elastic beanstalk.

One half of me thinks it would make sense to check that if the name and/or source bundle has changed that the "update" changes to a "create". The other half thinks this is missing the point of terraform.

What do you think?

[stack72]

Hi @jwconway

Please can you add a sample config that would help us to understand the issue you are having and see if there is a design flaw?

thanks

Paul

[jwconway]

Hi @stack72

Were using the following:

resource "aws_elastic_beanstalk_application_version" "default" {
   name        = "${var.eb-app-name}-${var.build-number}"
   application = "${var.eb-app-name}"
   description = "application version created by terraform"
   bucket      = "${aws_s3_bucket.default.id}"
   key         = "${aws_s3_bucket_object.default.id}"
}

Like i say, i think terraform is doing its job in tracking a single resource but i dont think its useful for an application version in elastic beanstalk. If i change ${var.build-number} from "v1.0" to "v1.1" (new build) we lose "v1.0" as an application version in the beanstalk application.

[radeksimko]

Hi @jwconway thank you for raising this issue. (Unfortunately) it's not Beanstalk-specific problem. We don't have a good support for "versioned" resources in the current implementation of the schema and/or other parts of Terraform's core. This isn't something that can be easily addressed on resource/provider level at this point.

Here's an issue discussing the problem in more wider context (also mentioning aws_elastic_beanstalk_application_version) so I'd recommend subscribing to it: https://github.com/hashicorp/terraform/issues/8765

[giantryansaul]

Wouldn't a simple solution to this be to provide a do_not_delete_version (bool) option to this resource? The logic all seems to be there. I can get the desired effect by removing the version resource through terraform state rm. I'd rather not manage this outside of terraform apply though. I'd argue this is different than the more conceptual idea of terraform managing states. It seems to be more of a feature of the version resource. Heck its even in the name :)

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[bdemers]

+1 for something like do_not_delete