Snowflake-Labs / terraform-provider-snowflake

Terraform provider for managing Snowflake accounts
https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest
MIT License
552 stars 420 forks source link

[Bug]: Resource Snowflake_Schema fails to create schema #3190

Closed dushoup closed 1 week ago

dushoup commented 1 week ago

Terraform CLI Version

1.9.8

Terraform Provider Version

0.97.0

Company Name

Pay Near Me

Terraform Configuration

resource "snowflake_schema" "stage" {
  name                = "${var.project_name}_STAGE"
  database            = var.db_name
  is_transient        = false
  with_managed_access = false
}

Category

category:resource

Object type(s)

resource:schema

Expected Behavior

The provider running with sysadmin role so this shouldn't be an issue.

Using sysadmin role: It should create a schema in the passed in database name.

I have verified that all the vars are being set. Other steps and resources are creating fine.

Actual Behavior

Fails with

schema name: "DEV"."COOL_PROJECT_STAGE", err: [errors.go:22] │ object does not exist or not authorized

Steps to Reproduce

Copy the above Hard code values for clarity run terraform apply See error.

How much impact is this issue causing?

High

Logs

No response

Additional Information

If I create the Schema manually with the sysadmin: I can then import and now the terraform can manage the resource. It does constantly report as change pending. The only field it lists is description_output

Would you like to implement a fix?

sfc-gh-asawicki commented 1 week ago

Hey @dushoup. Thanks for reaching out to us.

How do you create the database? Is it created in the same terraform deployment? Do you create it manually? If you have it in the same config, then it can result in the described error because you have no implicit or explicit dependency between the schema and the database so terraform cannot know the ordering in which it should create the resources (first database, second schema) while building the object graph. You could either use:

dushoup commented 1 week ago

Thanks for the response. The database is "static" from the point of view of the package experiencing this issue. It's built by a "core" terraform repo that controls the DB and other account level objects.

So from the point of view of this package it's definitely there. It feels like a weird privilege issue, maybe around the description_output but I run the terraform as sysadmin. When I manually create the schema's I use the same role. I'm wondering if there is a pre or post step in the terraform.

I if I get a chance I'l see if I can lower the debug level in terraform and see if I gleam anymore detail.

dushoup commented 1 week ago

I'm going to close the ticket but I want to close the loop on what I did wrong.

In this module I didn't declare or ensure the "provider" or "provider alias" was using the sysadmin role specifically.

Our schema module was using our default provider and it wasn't on the sysadmin role.

Thank you for the support.