[Feature]: Allow easier management of Snowflake user TYPE

[drew-jess]

Use Cases or Problem Statement

The Snowflake provider supports several user resources:

• snowflake_user
• snowflake_service_user
• snowflake_legacy_service_user

The main difference between these appears to be the TYPE attribute configured on the user (PERSON, SERVICE or LEGACY_SERVICE, respectively).

If I create a snowflake_user resource and later try to convert it to a snowflake_service_user, I should be able to use a moved block (link) to do so:

moved {
    from = snowflake_user.foo
    to = snowflake_service_user.foo
}

Currently, that is not possible - the provider throws an error:

Error: Move Resource State Not Supported
The "snowflake_service_user" resource type does not support moving resource state across resource types.

The only other solutions are to:

• Recreate the resource (causes downtime, as the old resource is destroyed)
• Perform manual state modifications using terraform state mv/rm and terraform import (impacts development workflows by requiring a manual "freeze" of state)

Setting a user's TYPE is particularly important with the advent of changes to MFA on user accounts in Snowflake (see BCR-1784, etc).

It should be straightforward for users to adjust the TYPE of a user without having to recreate it or perform manual state modifications.

Category

category:resource

Object type(s)

resource:user

Proposal

Please consider either of the following:

• Consolidating the user resource types into snowflake_user and providing a type = [HUMAN|SERVICE|LEGACY_SERVICE] attribute rather than separate resources
• Support the ability to migrate one resource type to another using moved blocks

This would ease of correctly ensuring all provider-managed Snowflake users have the correct TYPE attributed to them.

How much impact is this issue causing?

Medium

Additional Information

See also Support Case: 00938884

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-asawicki]

Hey @drew-jess. Thanks for reaching out to us.

The decision to split the user resource into multiple resources was conscious and aligned with our strategy to have smaller, dedicated, and easy-to-maintain resources. The type is NOT the only difference between these user types. Therefore we won't consolidate them back into one resource.
The second proposed option, i.e., the moved block, is not available in the currently used SDKv2 (check this comment for more context: #3327 (comment)). The removal from state and reimporting is the only recommended way in this case, as confirmed by HashiCorp here: hashicorp/terraform-plugin-sdk#1411 (comment).

[drew-jess]

Thank you, that's unfortunate. Just for my own interest, what are the rough timelines on moving to terraform-plugin-framework? Appreciate you won't be implementing this issue anytime soon - just out of curiosity.

[sfc-gh-asawicki]

TL;DR
We will plan it after GA. We can't commit to any timeline at the moment.

Longer context
We would really like to move to the new Terraform Plugin Framework as soon as possible. The currently used SDK has many limitations, which make us add multiple workarounds. It makes the provider's logic more complex and harder to maintain. On the other hand, it also limits our users (the moved block is one example, but there are more, like handling lists/sets, modifying plans, etc.).
However, the current provider does not have official Snowflake support. It means that all potential problems go directly through our small engineering team. We can't provide official support without moving the provider to the GA. Because of that, we put the main focus on getting to V1 first and now to get to GA. This will allow us to "do more" in the long run. It includes changes like migration to the new framework but also closing the wide feature gap we have.
I will summarize it next week as our new roadmap entry, but this short explanation should give you a better view of our current priorities.

[drew-jess]

Appreciate your candid response and appreciate the challenges ahead.

Thanks for all all of the work on this provider - I'll keep an eye out for the roadmap update and will close this issue off.