Migration from snowflake_role_grants to snowflake_grant_account_role

[Bryan-Meier]

Terraform CLI and Provider Versions

Terraform v1.5.5
on windows_amd64

• provider registry.terraform.io/hashicorp/aws v5.44.0
• provider registry.terraform.io/snowflake-labs/snowflake v0.88.0

Terraform Configuration

terraform {
  required_version = ">= 1.1.1"

  cloud {
    hostname     = "backend.api.env0.com"
    organization = "xxxxx"

    workspaces {
      name = "x"
    }
  }

  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "= 0.88.0"
    }
  }
}

Expected Behavior

The snowflake_role_grants resource is destroyed and the snowflake_grant_account_role resource is created and in good state in the target snowflake account.

Actual Behavior

The destroy of the snowflake_role_grants resource and the create of the snowflake_grant_account_role start executing at the same time in Snowflake upon apply. The destroy completes after after the create. Due to this timing and lack of sequential flow the resource the end result is the create is as if it never happened.

Steps to Reproduce

1. Remove snowflake_role_grants resource from .tf file
2. Add snowflake_grant_account_role resource to .tf file
3. run terraform plan
4. run terraform apply

How much impact is this issue causing?

High

Logs

No response

Additional Information

We have thousands of snowflake_role_grants instances that need to be replaced. We don't have a clear understanding what the migration pattern should be for deprecated resources like this. I know I am over simplifying this but it would seem to me that it would work fine if the destroy and create operations were not asynchronous and the destroy finished before create executed.

[sfc-gh-jcieslak]

Hey hey 👋
Afaik, that's more of a Terraform issue than the provider one, but I already had a similar issue you can look at (here). The result of that conversation was a migration guide we wrote here. It describes how you can migrate from deprecated resources to the new ones with "no downtime" approach, meaning nothing will be destroyed/revoked on the snowflake side. I also suggest automating it with a simple script to e.g. generate import blocks, it should pay off when you have thousands of roles. Removing the deprecated resources and replacing them with new ones in the second terraform apply would also work, but that would revoke any grants from them and would create a downtime until new roles are created.

[Bryan-Meier]

Hey @sfc-gh-jcieslak, thanks for the reply and the resources this is helpful. It's going to be bit of work for us since we have about 3000 resources that need to be replaced across multiple internal/local modules. Either way, your info confirms one of the approaches I was thinking about after my original post. Thanks again!