terraform-provider-heroku
terraform-provider-heroku copied to clipboard
Tell heroku_addon that the addon cannot update its plan
Some Heroku Addons (for example Heroku PostgreSQL) cannot update their plan in place. The heroku_addon resource assumes all addons can. Updating the plan of a heroku_addon with the posgresql addon results in a unapplyable valid plan.
Feature Request:
-
The provider automatically detects (if this information is available through the API) that the addon's plan cannot be updated and forces recreation of the resource.
-
Add a
recreate_on_upgrade = true|falseargument toheroku_addonto force destroy and recreate rather than update in-place.
Terraform Version
v1.0.1
Heroku Provider Version
4.5.1
Affected Resource(s)
- heroku_addon
Terraform Configuration Files
resource "heroku_app" "api" {
region = "eu"
name = var.app_name
}
resource "heroku_addon" "database" {
app = heroku_app.api.name
plan = "heroku-postgresql:${var.db_plan}"
}
Expected Behavior
The provider detects that heroku-postresql cannot change plan in-place and force recreation of the resource when applying with a different plan.
Actual Behavior
terraform produces a plan that cannot be applied.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform apply -var db_plan=hobby-basicterraform apply -var db_plan=standard-0
For anyone interested, my current workaround is this
resource "heroku_addon" "database" {
for_each = toset([var.db_plan])
app = heroku_app.api.name
plan = "heroku-postgresql:${each.key}"
}
Hi @Floby,
Thanks for reporting this issue! We'd definitely need to modify heroku_addon's behavior to account for non-updatable addons.
The proposed solution for an additional boolean type attribute on heroku_addon would not force a resource recreation event unless the behavior was to toggle recreate_on_upgrade to true/false every time you wanted to trigger a recreation. This sort of behavior would not be desirable and introduces a superfluous attribute is not needed in the modification of an addon. It is likely we'll need to leverage a similar solution implemented in the heroku_build resource to specifically designate the heroku_addon.plan attribute for recreation based on the addon prefix name (heroku-postgresql).
I'll take a look at this in the coming days.
thanks for your reply ! I didn't know if this sort of information was available through the API so I added the 2nd proposition just in case.