Allow renaming a folder name without destroying the folder

[lemoo5sg]

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]

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]

@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.

[lemoo5sg]

@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]

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]

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 ;)