Are resources expected to be fully owned by the provider or allow out-of-band changes? #740
-
Had this thought while working through issues related to Is this resource expected to fully own and manage the grants of the role or work in conjunction with out-of-band grants.Specifically, the issues reported #189 and #512 with a fix in #520 seem to be operating under the assumption that there might be multiple Terraform or other resources controlling grants on a role. The described problematic behavior is not an issue if you expect that TF owns the resource and there's only one controlling the grants. In that case, if a grant is added outside of resource, say manually in SQL, and then the resource is destroyed, you would expect that all grants including the one from outside TF will be removed! #520 also had the unexpected consequence that there's no way to import role grants (see #596). It limits the role grant management to what's explicitly created in TF and that's it. This is difficult to get around. Even with a custom import function and not relying on the default pass through https://github.com/chanzuckerberg/terraform-provider-snowflake/blob/bde252ef2b225b128728e2cd4f2dcab62a65ba58/pkg/resources/role_grants.go#L45 it's not clear how one would specify which grants should be tracked and would likely have to be enumerated in the import statement. Perhaps the latest TF framework https://www.terraform.io/docs/plugin/which-sdk.html#do-you-need-more-features-than-sdkv2-provides- would solution that allows READ to see everything but only manage what's in TF
however this change is not near term. SuggestionMy current thought is to split this into two resources. One that manages all grants on a role and one that manages a single grant at a time. This would be similar to the two resources in the aws provider that control a role policy attachment I'm happy to do as much of the work outlined above as I can if that is the path that seems reasonable to take. Very open to thoughts comments and suggestions. Would especially love to hear from users that have been working through these issues already: @cstkpk, @knighteagle789 and @wconti1017 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Closing as the underlying issues have all been closed under #2755. No longer aware what direction this provider is going in but this is likely stale. |
Beta Was this translation helpful? Give feedback.
Closing as the underlying issues have all been closed under #2755. No longer aware what direction this provider is going in but this is likely stale.