Support a means of attaching the same add-ons of one app to another

[robertcnix]

This is a feature request.

It would be incredibly useful if the heroku_app data resource returned the attached add-ons. Or maybe even more useful, the heroku_addon data resource could accept an app name in addition to the add-on name (only one required).

The value here is with respect to data-driven infrastructure. Being able to define a list of apps that contain the add-ons needed for another app allows for the separation of infrastructure .tf definitions from the description of a service-app (in .tfvars). For example, I'd like developers to be able to specify the add-ons their service needs in a simple list in a .tfvars file without having to touch any .tf files.

The problem is that the only place the add-on name is provided seems to be the output of the heroku_addon resource so if the definition of the add-on is in another terraform definition, it requires accessing the state of the other resource which is more cumbersome than using data resources.

Additional, small gripe, this is a little misleading, implying that the name is an app name but it's actually the add-on name:

data "heroku_addon" "from_another_app" {
  name = "addon-from-another-app"
}

Terraform Version

Terraform v0.12.3
+ provider.heroku v2.0.1

Affected Resource(s)

data resources:

• heroku_app
• heroku_addon

Terraform Configuration Files

It would be nice to do something like this:

data "heroku_addon" "addons" {
	app = "addons-from-this-app"
}

resource "heroku_addon_attachment" "attachments" {
	app_id  = "${heroku_app.default.id}"
	addon_ids = "${data.heroku_addon.addons}"
}

where data.heroku_addon.addons is a list and allows for attaching all the same add-ons to another app.

[bernerdschaefer]

I'm not certain about fetching all addons or attaching many addons at once, but the platform API does support setting custom names on addons as well as fetching an addon by that custom name, namespaced by app.

The provider already supports giving add-ons a meaningful name (see DevCenter on meaningful names):

resource "heroku_addon" "messaging" {
  app = "myapp"
  plan = "heroku-kafka:private-5"
  name = "messaging"
}

So if the data resource supported providing an app name / id, we could look up the add-on without knowing its globally unique name:

data "heroku_addon" "messaging" {
  app  = "myapp"  // or app_id? Either way, this doesn't exist, yet
  name = "messaging"
}

I think that would solve the problem, and should be a relatively straightforward change for the addon data source to call out to /apps/{app_id_or_name}/addons/{name} instead of /addons/{name} when the app field is set.

[robertcnix]

@bernerdschaefer

Giving the add-on a custom name would also be perfect as long as I can give it the same name as its app and if that name does not impact the config var name when attaching it to other apps.

But, i just tried and I get:

Error: "name": this field cannot be set

	on main.tf line 22, in resource "heroku_addon" "addon":
	22: resource "heroku_addon" "addon" {

If I can assign add-on names in the way i described above, I don't need anything else because I can obtain the add-on by add-on name since I can compute it from the details of the service in which i'm deploying.

[bernerdschaefer]

Giving the add-on a custom name would also be perfect as long as I can give it the same name as its app and if that name does not impact the config var name when attaching it to other apps.

Setting a custom name is separate from changing the environment variable it's attached with, covered in the API reference docs.

Re-reading those docs, I see that the custom addon name still needs to be globally unique, but you already mentioned that should work for you since you can use the app name in the addon name

But, i just tried and I get:

Error: "name": this field cannot be set

	on main.tf line 22, in resource "heroku_addon" "addon":
	22: resource "heroku_addon" "addon" {

Bah! You're right that this is currently a read-only field. I think that's just an oversight; it's definitely supported by the API.

[robertcnix]

Re-reading those docs, I see that the custom addon name still needs to be globally unique, but you already mentioned that should work for you since you can use the app name in the addon name

Indeed, our app and add-on names are derived from team name, space name, and logical add-on name and shortened (to fit into the 30 char limit) in a way that is very likely to be globally unique.

[davidji99]

@robertcnix #210 was merged in and released back in July. If that solves your issue, please close this issue. Thanks!

[robertcnix]

@davidji99 I'll test it out within the next few days and update the issue accordingly. Thanks!

[robertcnix]

@davidji99 Can you help with the usage for heroku_addon data resource?

All i have access to is the app name, not the add-on name but when i try to use id or app_id:

Error: Missing required argument

	on main.tf line 51, in data "heroku_addon" "addons":
	51: data "heroku_addon" "addons" {

The argument "name" is required, but no definition was found.

Error: Unsupported argument

	on main.tf line 53, in data "heroku_addon" "addons":
	53:   app_id = "my-app-name"

An argument named "app_id" is not expected here.