[Snowflake Official] 0.56.2 Grant Resource ID Issues #1633
Replies: 1 comment
-
|
Having looked into the source code in the last weeks and also fixed some smaller bugs, I have noticed some downsides of the current grant implementation, especially regarding the IDs. I have also investigated how to add the on_all option to grants ( |
Beta Was this translation helpful? Give feedback.
-
We recognize that we have caused frustration to many of our users and we apologize for that. I write this to lay out the current situation and to seek your input on our path forward towards a stable solution.
Version 0.56.2 of the provider introduced a breaking change to grant resource IDs, which has caused upgrade issues for many users. The subsequent fixes that have been made to address the initial problems have not fixed the issue for all users. I cover here why reverting the change is not feasible, potential solutions, and what to expect going forward.
HISTORY
Prior to 0.56.2 all grant resources shared a common ID format. This was either 5 or 6 parts (depending on when the resource was originally created), and typically follows the form:
6 part
Or:
5 part
The format of these grant IDs is usually sufficient, but there are a few issues:
Because all the grant resources shared the same logic, it was impossible to fix some Read / Import bugs on certain grant resources.
Shares were not included in the ID
Importing grants didn’t capture the full state of the resource.
Account level grant objects do not have schema or object names and procedure / function resources which have additional parameters where awkward.
ORIGINAL FIX
As part of 0.56.2, each grant resource was given its own ID parser, allowing for more succinct yet complete IDs. Typically, these would be 7 parts, although for account level object grants, these would be as low as 4 or 5.
For example:
Or for account objects:
As you can see, a distinguishing factor of the new IDs is the use of the snowflake emoji ❄️. The intention was to support old ID formats as they were. The emoji were not the reason behind the change.
In addition to the grant ID format changes, changes were also made to add custom importers to fix some of import issues, as well as changes to the Read function of grant resources to fix some other issues.
UPGRADE PROBLEMS AND FIXES
Immediately it became evident that the 0.56.2 change did not go as smoothly as planned.
While the emojis were a target, I identified the root problem as older 5 part ID formats that were used prior to Roles being added to the ID. I appreciate those of you who filed issues and/or brought these edge cases to my attention. I have been fixing every case I am aware of in subsequent releases. It is clear that additional issues remain. I am working to resolve these issues as swiftly as possible. I have been including automated testing to prevent further regressions to these cases as I solve them.
Unfortunately, it is not straightforward for us to add in additional tests for the cases we haven’t previously tracked. It is difficult for me to find these kinds of errors because they do not occur when creating the resource in the current version, only when using one of these older IDs, whose structure is not always clear or easy for me to replicate.
Due to a consensus against the use of emojis, I have changed the ID logic back to using “|” as the primary delimiter.
CURRENT CHALLENGES
It is not possible to simply revert the commit as people have suggested. Users leveraging the new format would be similarly broken if the new format were no longer compatible. Furthermore, it is necessary to decouple the ID logic for the grant resources to resolve the source of other previously unfixable read / import errors.
My plan is to prioritize fixing every reported problem with the older 5 part ID formats. I do not have the complete list of which resources are affected, which is why the “fixes” have not resolved every issue as of the latest version.
PROPOSED SOLUTION
Continue to Fix Errors as they are identified
This is the current path. It’s the quickest and more straightforward solution. If there are any issues with the current version parsing old IDs, file an issue and I will resolve it and add a test case to make sure it does not happen again.
ALTERNATIVE SOLUTIONS CONSIDERED
This one needs some explanation due to nuance. In Terraform, IDs are supposed to be used to uniquely identify a resource in a cloud provider API and be immutable. However, Snowflake does not have immutable IDs for resources. Object identifiers are made up of multiple parts (typically: "<db_name>"."<schema_name>"."<object_name>"), all of which may be renamed. Databases, schemas and objects can all be renamed, and there is no record of what the original name used to be anywhere. Therefore it may not be useful to parse the ID at all. Although we could go as far as using a purely random ID, it is still likely useful to use the original identifier since 99% of the time people are not renaming objects, and it is helpful to know which resource they are talking about when looking at the state file.
Besides the inherent risks in this approach, implementing this change would affect import of resources, meaning changes would need to be made to Read / Update functions for every resource, as well as adding in custom importer functions for every resource. This will take a long time to implement, but it is a sound change that fixes some of the ForceNew attributes on resources that really should not be ForceNew. We may choose to implement this idea in a v2 of the provider, but for now it is in the backlog.
Change the ID to the new format
Using d.SetID(), it is possible to change the ID of existing resources. If an old ID is detected (or an error parsing the ID is determined), it could trigger a subroutine to change the ID of the grant resource to the new one. This allows us to “update” all IDs to the new format. Since this is really just solution provider setup #1 + additional steps, and since it provides little incremental value, I do not think this change is worth implementing at this time.
Deprecate the Grant Resources Entirely, in Favor of New Resources
There is already a plan to deprecate the existing grant resources in favor of ones that more closely match the Snowflake API. We could just work on that and release them, deprecating the old ones in the process. However, this will take time to develop the new resources, and it doesn’t solve customers current needs. Therefore it cannot be the primary solution.
-Scott Winkler on behalf of the Snowflake Terraform Provider team
Beta Was this translation helpful? Give feedback.
All reactions