Open rvoitenko opened 1 year ago
Hi @rvoitenko, thanks for reaching out about this!
This is certainly a confusing and unintuitive scenario. For convenience, our public API endpoints for environments and configs reference projects by name, rather than by an immutable identifier. Our Terraform provider therefore can't tell the difference between a project rename and an attempt to move an environment from one project to another (which would absolutely require re-creation of the environment resource).
I'll chat with the team on some ways to solve this but we unfortunately don't have a good workaround at the moment. Sorry for the confusion!
But why environment name is immutable? Even if I made doppler_config not depend on output from doppler_environment and hardcode the names, it still want to re-create the config. Which make it impossible to rename environment without re-creating underlying configs.
For example I had this code:
resource "doppler_project" "project1" {
name = "project1"
}
resource "doppler_environment" "prod" {
project = "project1"
slug = "prod"
name = "prod"
}
resource "doppler_config" "prod_gh" {
project = "project1"
environment = "prod"
name = "prod_gh"
}
and I want to rename prod
to prd
:
resource "doppler_project" "project1" {
name = "project1"
}
resource "doppler_environment" "prod" {
project = "project1"
slug = "prd"
name = "prd"
}
resource "doppler_config" "prod_gh" {
project = "project1"
environment = "prd"
name = "prd_gh"
}
And this causes config to be recreated. As a potential temporary solution renaming can be done manually in UI, and then do terraform import of renamed resources. But terraform import doesn't work for doppler resources right now.
Doppler projects, environments, and configs can all be renamed via the Doppler Dashboard or API. However, the Doppler API (and the Terraform provider by extension) associates these resources with their parents via the name of the parent.
In your example, doppler_environment.prod
is linked to its project via the "project1"
name; this is true whether you hardcode the name or reference it from the project resource. The doppler_environment
's project field is marked as ForceNew
in the Doppler Terraform provider because you can't change an environment's project in Doppler; changing the project would require deleting and recreating the environment in the other project. Because the Doppler API associates environments with their projects using the project name, the Terraform provider doesn't know whether you're changing the environment's project name because the project was renamed or because you're trying to move the environment from one project to another.
This scenario is definitely nuanced so please let me know if there's more I can clarify!
The import solution is interesting. I'll chat with the team about that. Ideally though, you'd be able to perform this operation in Terraform alone.
Thank you for your explanation.
I'm not terraform developer expert, however other providers are able to handle such situations.
As example GitHub provider can be taken. If you have github_repository
resource and github_branch
resource referenced to repo name; when you rename github repo, it doesn't re-create the branch. I guess an additional attribute called etag
used with git repo, and it remains static since repo creation time. So probably, github provider understand that changing repo name doesn't change the etag, so github_branch
remains unchanged.
Thanks for that example! We'll take a closer look at the GitHub provider for reference. The Doppler API doesn't have an immutable public identifier for projects today but it's something that could be added.
I had a project with a few envs and configs, created by terraform. Then I added secrets in configs and github integration. At some point I decided to rename the project in terraform. Terraform did rename the project but also re-created all envs/configs. So all secrets were removed, and integrations were as well.
Example code:
Then I renamed
prod
environment toprd
:This caused
prod_gh
config to be re-created and all secrets in it were removed as well.Expected behavior: envs updated in-place(renamed), without impact on configs.