Open joaocepaa opened 10 months ago
Hey @joaocepaa. Thanks for reporting the issue.
I am not convinced that this should be natively handled. I will consult with the team and get back to you.
Does declaring the source account as one of the allowed_accounts (either in the first or subsequent run) work as a workaround for now?
@sfc-gh-asawicki thank you very much for your reply.
I personally think that the provider should handle this natively because then changes to the source primary failover group can have an impact, and the final tf state should be 100% aligned with the resource created and seen in Snowsight. Also, the official snowflake documentation is clear that allowed_accounts should only contain information about target accounts (the target account or list of target accounts) but again just my opinion.
Yes, adding the source account to the allowed_accounts list as a workaround works.
@joaocepaa I'm glad the workaround works; please use it for the time being.
We will take your opinion into consideration during our talks. After all, we want to follow our users' suggestions if they are consistent with our bigger assumptions.
Terraform CLI and Provider Versions
Terraform version: 1.4.2 Snowflake provider version: 0.73.0 (Snowflake-Labs/snowflake)
Terraform Configuration
Expected Behavior
The provider should natively handle the fact that Snowflake adds the account where the source failover group is located to allowed_accounts, so that on a run after the first one it doesn't detect changes.
Actual Behavior
After the first creation of the source_failover_group resource, Snowflake internally adds the source account to the allowed_accounts list without indication. This leads to Terraform detecting a change in the allowed_accounts during subsequent terraform apply executions, even when no changes are made to the configuration.
Change that it detects by running a second time without me changing anything:
Steps to Reproduce
How much impact is this issue causing?
High
Logs
No response
Additional Information
This behaviour seems to be an unintended side effect of the Snowflake provider's interaction with the Snowflake platform, particularly in a cross-region, multi-account setup. There has been no recent change in the environment or workflow that might be relevant to this issue. No workaround has been found at this moment.