Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow renaming a folder name without destroying the folder #41

Open
lemoo5sg opened this issue May 17, 2022 · 5 comments
Open

Allow renaming a folder name without destroying the folder #41

lemoo5sg opened this issue May 17, 2022 · 5 comments
Labels
P3 medium priority issues refactor Updates for readability, code cleanliness, DRYness, etc. Only needs Terraform exp. triaged Scoped and ready for work

Comments

@lemoo5sg
Copy link

lemoo5sg commented May 17, 2022

TL;DR

Note: We have originally opened issue 40, which has been closed because similar to issue 38.
However issue 38 is also closed with no change delivered, stating that this is due to a terraform constraint.
However we reject this reason, there is a proposed solution.

Request:
If we rename a previously created folder through names variable, terraform will destroy the folder and recreate a new one, as the folder name is used as a for_each key.

Note 1: the workaround to manually remove the folder from the state and delete the folder is not acceptable, the goal is to automate with Terraform and avoiding manual actions.
Note 2: Also the potential workaround to add the new folder name as a new value in the list and keep the old name as it is is not acceptable as we do not want to keep a second folder, we need a renaming.

Terraform Resources

names = ["previous_name"]
changed to:
names = ["new_name"]

-------------------------------
Plan result:

# module.module1.google_folder.folders["previous_name"] will be destroyed
[...]
# module.module1.google_folder.folders["new_name"] will be created
[...]

Proposed Solution

The variables needs to be adapted to isolate the requested folder display name from the for_each resource key to allow renaming.

For example:
instead of flat names variable, use a list such as:
     names= [
                      {folder_key = "my_folder_1", folder_name= "requested_display_name"},
    ]

and for folders resource, replace toset with something similar to:
resource "google_folder" "folders" {
  for_each = {for folder in var.names:  folder.folder_key => folder}
  display_name = "${local.prefix}${each.value.folder_name}"

This way, when we change folder_name later to "new_name", we do not change folder_key, the state key is unchanged and the folder is renamed as expected.

Originally posted by @lemoo5sg in #38 (comment)

@lemoo5sg
Copy link
Author

Hi,
Another alternative might be to keep names variable as it is and to use count instead of for_each, to use indexes as tf state resources keys instead of the names, however on one side the impact on folder_admin_roles_map_data & owners resources has to be assessed and the other side it will create an implicit ordering of the names, new folders will have to be added at the end to have no impact on the existing ones.

resource "google_folder" "folders" {
  count= length(var.names)

  display_name = "${local.prefix}${var.names[count.index]}"
  parent       = var.parent
}

@bharathkkb
Copy link
Member

@lemoo5sg Are moved blocks another alternative you could consider? The first approach maybe possible to implement but it would be a breaking change and some added complexity.

@bharathkkb bharathkkb added triaged Scoped and ready for work refactor Updates for readability, code cleanliness, DRYness, etc. Only needs Terraform exp. P3 medium priority issues labels Aug 25, 2022
@lemoo5sg
Copy link
Author

lemoo5sg commented Aug 31, 2022

@bharathkkb thanks for your comment ; nope, moved blocks (or state mv commands) mean additional / manual actions each time, it's better that the module handles renaming by design.

@brettcurtis
Copy link

I'm playing around with some code to get by this myself, and it still feels pretty ugly :D - NOTE: I'm not using this module but what I'm wondering is if anyone has any links to good examples of folks using this resource in a reasonably DRY way? At this point, for me, it's more around subfolders and just copy-pasting resources with different parent keys.

@Ludovic-Emo-Pyl-Tech
Copy link

Ludovic-Emo-Pyl-Tech commented Dec 24, 2024

Hi,
Could someone please confirm if this issue could been addressed or is already resolved through another case?
I’m currently avoiding the use of this module and relying on my own implementation due to this concern.

(lemoo5sg but now working for another company ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 medium priority issues refactor Updates for readability, code cleanliness, DRYness, etc. Only needs Terraform exp. triaged Scoped and ready for work
Projects
None yet
Development

No branches or pull requests

4 participants