Tell heroku_addon that the addon cannot update its plan

[Floby]

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:

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

2. Add a recreate_on_upgrade = true|false argument to heroku_addon to 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:

1. terraform apply -var db_plan=hobby-basic
2. terraform apply -var db_plan=standard-0

[Floby]

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}"
}

[davidji99]

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.

[Floby]

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.