[Feature]: Back Compatibility For Providers <1.0

[DustinMoriarty]

Company Name

Zoom

Use Cases or Problem Statement

We are already using the Snowflake terraform provider extensively in several repositories managing thousands of objects. I see that in version 1.0, there are several cases of breaking changes, with some providers not only being deprecated but dropped completely. Unlike a normal software library, when a terraform provider makes a breaking change, it is not simply a matter of refactoring code. Existing terraform state files must be migrated.

In the case of a new resource replacing an old resource, each resource must be removed and then imported. This process is often very manual and must be repeated differently in each environment. Then we must make sure that the generated plan will not make any changes to the actual resource under terraform control. With a real terraform configuration controlling many different resources, removing and re-importing resources is a very big task which also introduces risks of unintended changes to infrastructure. This introduces a large unplanned project for users without any business value to justify it. We will end up stuck on the 0.* releases for those existing repositories that no one has time to migrate.

Category

category:resource

Object type(s)

No response

Proposal

For the resources which where deprecated in version 1, release a 1.* version which maintains the previous resource interfaces. A deprecation note can be added. However, the resource should not be dropped. Terraform resources need to be stable interfaces that do not change every time a new developer takes over the project. If someone wants to make a better resource, great. However, there are very few cases where a resource should no longer be supported. If changes are needed, it is better to make incremental changes to the same resource while maintaining a consistent resource type.

How much impact is this issue causing?

High

Additional Information

This will prevent us from being able to update to 1.0 for our existing terraform repos. It also degrades our overall confidence in using the Snowflake terraform provider in general because it shows that Snowflake is not maintaining a stable interface.

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-asawicki]

Hey @DustinMoriarty. Thanks for reaching out to us.

A short context for all the breaking changes you are referring to and the state of the provider:

• the provider was still in an experimental state before the V1 release (check the disclaimer in our registry docs: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/0.99.0/docs and on GH: https://github.com/Snowflake-Labs/terraform-provider-snowflake/tree/v0.99.0?tab=readme-ov-file#snowflake-terraform-provider)
• breaking changes in 0.x.x versions are expected and were summarized in the migration guide: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md
• 0.x.x projects do not guarantee a stable API
• deprecated resources were marked appropriately with the removal promise This resource is deprecated and will be removed in a future major version release.
• We released v1.0.0 of the provider right before the Christmas break; starting with this version, breaking changes will require bumping the major provider version (for the stable resources; check the preview resources in V1: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/1.0.0/docs and https://registry.terraform.io/providers/Snowflake-Labs/snowflake/1.0.0/docs#preview_features_enabled-3); we will also deprecate the resources without removing them (but keep in mind that they will be removed with the next major version of the provider).
• It also degrades our overall confidence in using the Snowflake terraform provider in general because it shows that Snowflake is not maintaining a stable interface. - 0.x.x version was never declared a stable version (check the disclaimers) and all the deprecated resources were meant to be removed completely with the V1.

[sfc-gh-asawicki]

Please contact your Snowflake account manager and ask them to set up a meeting with Swathi and me, so that we can work something out.

[sramshaw-yolabs]

what in the actual....?

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

Why in the world do you deprecate/rename a resource with NO changes to the spec and then force people to manually state rm and state import? when this should be easily supporting the moved tf block?

[sfc-gh-jcieslak]

Hey @sramshaw-yolabs 👋
The grant resource deprecation and removal were added for consistency purposes and were an addition to already ongoing grant-related resource refactoring and deprecation/removal of other old grant resources. We considered the moved block as soon as it was released, but unfortunately, it's not possible to use it in Terraform's SDKV2 that we currently use for provider development. The feature is only available in the new plugin framework that we are planning to adopt someday. For now, there's not much we can provide from our side, as the tools we are working with are pretty limiting in that regard. We filed a ticket in the SDKV2 repository to see if this feature could also be implemented in the SDKV2, you can follow it here. Thank You for your feedback, we are aware that the migration is not an easy task, but there's little we can do at the moment.