Help users migrate resources from the Gsuite provider to Google Workspace provider

[megan07]

Follows #94

I'd like to discuss writing a script to help users migrate from the GSuite community provider to the Google Workspace provider. For users who have many resources, bulk import is very painful, it'd be nice if we can contribute to helping them write the script, or creating a tool that will nicely do it for them. This issue is a placeholder for that discussion and will be updated after the team has come up with a clear path forward.

[ismith]

Hi! Is there work actively in progress on this? Weighing if we should charge forward manually, or hold off for a tool.

[megan07]

Hi @ismith! I can provide an update here. It is actively being worked on and is the highest priority for this provider at the moment. I'm finding it difficult to create a tool that can do this for us without knowing a user's exact configuration. For example, to parse a configuration file and all the associated interpolations, without knowing what was interpolated etc. I am continuing to look into different approaches, but have no promised deadline of when it will be or what it will look like.

Meanwhile, a tool like this may be helpful if you were to attempt it on your own while we continue to solve for this: https://github.com/minamijoyo/hcledit

[megan07]

A quick bump of #204 for those interested in helping us test this tool.

Thanks in advance!

[eitah]

By knowing a user's exact configuration do you mean you want representative samples of our terraform usage of any of the resources that would use the new provider, but especially those mentioned in https://github.com/hashicorp/terraform-provider-googleworkspace/pull/99/files Just trying to clarify what the call to action is.

[megan07]

Hi @eitah ! Thanks for asking - yea, any Gsuite Terraform configurations that you have. The basic configurations that we've worked with only really interpolate values, and that's about the extent of Terraform complexity that we've used there, so it'd be great if you had some configurations that used dynamic blocks, splat expressions, etc just to make sure that these things won't mess with the tool we're creating.

As for the resources, I'm not sure I have a preference to which resources are in the configuration, the more variety, the better, again, just to make sure the tool is picking everything up. Does that help?

[megan07]

Just wanted to add a gentle reminder here that I'll leave #204 open for another 15 days, and at the end of that time we'll use the configurations provided to verify our migration tool. Thanks!

[joe-a-t]

I'm having a bit of trouble generalizing/anonymizing our configuration enough to share in a reasonable way. Would it be possible for you to share the migration tool so that we could test running it on our end with a backup of our state file and let you know what happened/if there are any issues? That would probably be a lot easier for everyone if we only have to reproduce snippets where we know there is an issue.

[joe-a-t]

@megan07 any update on this? I'm happy to dry run any draft of the migration tool on my end if that would be helpful.

[joe-a-t]

@megan07 any update on the status of this tool? I'm happy to dry run any draft of the migration tool on my end if that would be helpful.

[tejavar]

Hi @joe-a-t thanks for getting back regarding the credentials for the migration tool. For Q1, We did not prioritize tool and hence won't be working on this. But please do feel free to comment or add your use-cases on high-level so that it will help us re-prioritize this.

[joe-a-t]

Hey @tejavar. We are entirely blocked on using this provider until this tool comes out since the migration process would be unbelievable painful for us without it. If we have to keep using the old deprecated gsuite provider because the migration tool doesn't exist, that's just what we will have to do.

[jazzlyn]

Hi, @joe-a-t in the meantime hashicorp provided an update guide in the provider documentation, see https://registry.terraform.io/providers/hashicorp/googleworkspace/latest/docs/guides/upgrade_guide. It covers the changes that have to be done when switching providers.

@megan07 maybe it would be valuable to add to the guide that the resource type for group_member has to be defined (default: USER) if the member that has to be added is a group (group in group) which makes it required then. this was not necessary with gsuite.

resource "googleworkspace_group_member" "member" {
  type     = "GROUP"
}

[joe-a-t]

Unfortunately that upgrade guide doesn't help at all with (or even document) the required adjustments to the Terraform state file, which is the actual issue for us given the scale of our usage.

[jazzlyn]

@joe-a-t
Regarding state file. Since a migration with terraform state replace-provider deviavir/gsuite hashicorp/googleworkspace did not work because of resource type mismatches, I did a fresh import. See my steps below.

Prepare import:

• create state backup file
• create sh file
• run terraform state list and copy/paste output to sh file (I usually create a backup of the state list as well)
• add terraform import to each line and adapt to match the import syntax (check resources documentation). it is possible to use email instead of ids.

terraform import googleworkspace_group_settings.test-settings [email protected]
terraform import googleworkspace_group_settings.example-settings [email protected]
[...]

• make sh file executable

Update configuration:

• add provider changes to configuration
• run terraform init

Fresh Import:

• run sh script: all resources should be imported
• run terraform plan
• do adaptions to configuration if necessary

Maybe someone else has another approach :-)

[joe-a-t]

Yeah that's unfortunately not scalable for us, we have literally thousands of resources in hundreds of state files that use this provider. Really wish we could get access to the tool @megan07 was making and looking for test configurations for.