terraform-provider-snowflake
terraform-provider-snowflake copied to clipboard
snowflake_schema is not idempotent
Provider Version
$ terraform version
Terraform v0.14.11
+ provider registry.terraform.io/chanzuckerberg/snowflake v0.25.24
Terraform Version
$ terraform version
Terraform v0.14.11
+ provider registry.terraform.io/chanzuckerberg/snowflake v0.25.24
Describe the bug
snowflake_schema is not idempotent.
Expected behavior
snowflake_schema is idempotent.
Code samples and commands
Create a snowflake_schema object managed by Terraform.
Then delete or rename it out-of-band from Terraform. Eg. ALTER SCHEMA "MY_DB"."MY_SCHEMA" RENAME TO "MY_DB"."MY_SCHEMA_BACKUP";.
Then run a plan/apply. It will error out saying:
Error: 002003 (02000): SQL compilation error:
Schema 'MY_DB.MY_SCHEMA' does not exist or not authorized.
Terraform should instead understand that the schema no longer exists and should offer to recreate it.
Having the same problem but I wanted to add a bit. I refactored the schema definition into a module so the name changed. The terraform apply had no way to understand that they were the same resource so it tried to create before deleting and I got a Object SCHEMA already exists error. The schema was deleted however so now when I run terraform plan I get a Schema 'SCHEMA' does not exist or is not authorized error.
Terraform version 1.1.6 Provider version 0.32.0
@MorganGellert were you able to find a workaround for the issue? I'm running into a similar problem but with pipe objects referencing a renamed schema
I ended up working around this by:
- Dropping all affected
STAGEs andPIPEs from the Snowflake database - Removing resources from the Terraform state (eg
terraform state rm 'module.my_snowflake.snowflake_stage.my_stage') - Rerunning my CICD pipeline to recreate and bring the resources back under Terraform's management.
However, this solution is not workable for everyone since it forces (extra) downtime due to having to delete and recreate resources. Destroying via Terraform also doesn't work because of this issue.
We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.