Are resources expected to be fully owned by the provider or allow out-of-band changes?

[frosforever]

Had this thought while working through issues related to snowflake_role_grants.

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
as then you're able to

Tell whether a value was set in the config, the state, or the plan.

however this change is not near term.

Suggestion

My 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
The current snowflake_role_grants resource would be similar to iam_policy_attachment in that it would maintain exclusive ownership of all grants of the role. If the resource is deleted then all grants, even those added outside the resource would also be removed. This would mean reverting #520 and setting role_name ForceNew: true (this should prob be done regardless!).
A new resource, perhaps snowflake_role_grant (open to naming!) would then be similar to iam_role_policy_attachment that would grant a single role to another, one at time. This would ignore other role grants be they in other snowflake_role_grant resources or out of Terraform entirely. If this resource is removed then only a single role grant is removed.
Importantly, and similar to the conflict between iam_role_policy_attachment and iam_policy_attachment, these two methods of granting roles would conflict and clobber one another.

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.
Thanks very much in advance to the reviewers for reading and maintaining this provider!

Would especially love to hear from users that have been working through these issues already: @cstkpk, @knighteagle789 and @wconti1017

[frosforever]

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.