terraform-provider-heroku

terraform-provider-heroku copied to clipboard

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.

Originally posted by @robertcnix in https://github.com/terraform-providers/terraform-provider-heroku/issues/209#issuecomment-519355804

@robertcnix moved your question to a separate issue.

---

My initial question is what if an app has multiple addons? How would decide which addon should represent the data resource if one only supplies an app id/name?

This question is pertaining to the add-on's app so it will never have more than one add-on, right? But as a general solution, the way i've used the CLI is like

heroku addons:info NAME --app HEROKU_APP

e.g. if we have three databases:

• DATABASE

• CONTENT_DATABASE

• USER_DATABASE

  heroku addons:info USER_DATABASE --app HEROKU_APP

The key point here is that because the add-name can be generated by Heroku, I don't have a means of obtaining that name to get a handle to the add-on using a data resource. I control the add-on's app-name and it's configuration variable name so those are what I need to be able to use to obtain a handle to the add-on.

Hi @robertcnix ,

Would you please add details (maybe open your own separate issue) about what exactly your Terraform configuration is and how you're getting into this state? Are you importing existing add-on resources? The basis of Terraform is that it controls the complete state of the resources, so how you get to this point is as important as the behavior you're seeing or desiring.

heroku addons:info USER_DATABASE --app HEROKU_APP

FYI That USER_DATABASE arg is the add-on's "attachment name". We have another issue #227 open to enable setting that in this Terraform Provider, but I'm still not clear what you're trying to do.

@mars

If i do this to get a handle to an addon, it can't be "USER_DATABASE", right? It's the globally unique name that Heroku generates?

data "heroku_addon" "addons" {
	name = "???"
}

I feel like I outlined the use-case pretty well in https://github.com/terraform-providers/terraform-provider-heroku/issues/209#issue-461008916 ?

That is correct @robertcnix ,

"USER_DATABASE" is the attachment name, the app-scoped config var name, configurable-on-create via Heroku CLI (issue #227, draft PR supporting configurable-on-create heroku_addon.attachment_name #231),

…while the heroku_addon.name is the add-on name, a globally-unique haiku ID, which recently became configurable-on-create in the provider v2.1.0.

@robertcnix It sounds like you're trying to use a pre-existing add-on in a Terraform configuration? Is that the case?

There are so many ways this could be solved, I'm really trying to understand what you're trying to do with Terraform.

We have a process where we create add-ons separately from the apps we deploy. For example, imagine an Operations team provides several databases that apps/services can attach and service-developers are not allowed to create and attach any other add-ons. Each app/service is effectively it's own, standalone terraform stack that can only reference existing add-ons. The names of add-ons it can access are computed based on where the app/service is being deployed (the space, region, and type of add-on, e.g. postgres). The idea was that an app/service's terraforming doesn't need to reference another stack's outputs to get the add-on names because we name everything uniquely and deterministically so a data resource is ideal.

As a practical example, imagine you're a service-developer and you want a user-database, you just specify that in your service's terraform.tfvars:

attach = [ "logging", "user-database", "caching" ]

The terraforming to accomplish this is not trivial so providing it may just confuse/complicate the question :-) and is the reason i'm beginning to consider an alternative approach, hoping that terragrunt or similar has a better technique. The big problem with this approach is that it uses count.index. While not a horrible problem, changing the order of the attachments will detach and reattach many/all of the app's addons.

So given the fact that I am considering an alternative, we should probably just hold on this question for the time being.

This question is pertaining to the add-on's app so it will never have more than one add-on, right?

Yeah in a scenario where you had an app called 'postgres' that only had the PG addon. But for users that have an app called 'rails-app' with PG and redis addon, that app has multiple add-ons. So if a user tries to set a data resource for heroku_addon when using just 'rails-app' app name, the data resource would need further information to know which addon to use in this case.

We have a process where we create add-ons separately from the apps we deploy.

Yeah, we do something similar as well.

Basically, this is what I need to be able to do:

resource heroku_addon_attachment db_main {
  addon_id = "my-addon"
  app_id   = data.heroku_app.app.id
}

data heroku_app app {
  name = "my-app-name"
}

I want to be able to use the application name from a data resource to obtain the app_id that is needed by the heroku_addon_attachment resource.