terraform-provider-digitalocean
terraform-provider-digitalocean copied to clipboard
Feature request: add 'project' property to droplet resource
Happily, support for the DigitalOcean 'projects' feature has been added to Terraform as per the discussion in #118 👍
It would be great if you could consider an enhancement by additionally implementing it as a property on the digitalocean_droplet
resource.
This would be similar to the way tags currently work, in that you can declare them as a resource or you can create/assign them on-demand as a property on the digitalocean_droplet
resource.
Use case: I have a number of different resource groups, stored in separate remote state files. My DigitalOcean Projects need to incorporate various resources from more than one of these remote states, which means I can't declare my digitalocean_project in a single apply
(afaik).
Proposal:
resource "digitalocean_droplet" "web" {
image = "ubuntu-18-04-x64"
name = "web-1"
region = "nyc2"
size = "s-1vcpu-1gb"
project = "my-project"
}
I second this, but would rather see it implemented as an association resource separate from the droplet. Although having both is ideal, creating an association resource as the MVP allows us to associate any valid resource type via its URN without needing to duplicate project
key functionality across all resource types.
Alternate proposal:
resource "digitalocean_project" "example" {
name = "example"
description = "A super, sexy example"
purpose = "Just trying out DigitalOcean"
environment = "Development"
}
resource "digitalocean_droplet" "web" {
name = "web-1"
region = "nyc2"
image = "ubuntu-18-04-x64"
size = "s-1vcpu-1gb"
}
+ resource "digitalocean_project_resource" "web" {
+ project = digitalocean_project.example.id
+ urn = digitalocean_droplet.web.urn
+ }
Additionally, this provides an alternative route to a race condition that exists with projects resources needing to reassociated upon alnum order changes, resulting in apply
disassociating all resources from their project at startup and re-associating them at the very end.. making the UI have a heart attack during buildtime.
@syntaqx I think your proposal appears to be a better, broader solution. However I don't quite understand how the digitalocean_project_resource
is associated with the digitalocean_project
in this example?
I'm on my phone so I don't have an exact example but URNs contain the item item keyed in them somewhere. They are unique in the system as well, so there's no need to say the type. I did miss providing a project ID though, I'll try to remember and add that when I'm home
Ah, great - it makes more sense with the project ID. Thanks @syntaqx
@orinokai Updated my original comment with the accurate update, good catch!
The docs at https://www.terraform.io/docs/providers/do/r/project.html say that not just droplets but load balancers, domains, volumes, floating ips and spaces can also belong to projects. It would be useful to support these resource types with this change.
I would like this feature too, and I think https://github.com/terraform-providers/terraform-provider-digitalocean/issues/258#issuecomment-504611562 is the best to ensure multiple resources can be added to the project.
Looking at: https://www.terraform.io/docs/providers/do/r/project.html, this seems to have been implemented now and this issue can probably be closed.
@BnMcG I don't quite see what you're referring to, both here and in your comment in #118. This issue is about the reverse direction (and discussion further evolved into implementing an "attachment" resource instead), associating a project to a droplet resource, rather than specifying droplets/other resources in the the project resource.
@lae, apologies, I misread this issue while looking for a solution to my own problem. In reference to #118, though, I think the implemented functionality does cover the request outlined in that issue.
https://github.com/terraform-providers/terraform-provider-digitalocean/pull/396 implements digialocean_project_resources
.
The downside of the association resource solution is that new resources are first created under the default project and only attached to the specified project at the end of the plan execution. This creates undesired noise in the activity logs for both projects.