Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag allowed_values order difference results in repeated apply #1806

Closed
chrisweis opened this issue May 15, 2023 · 6 comments
Closed

Tag allowed_values order difference results in repeated apply #1806

chrisweis opened this issue May 15, 2023 · 6 comments
Assignees
Labels
bug Used to mark issues with provider's incorrect behavior category:resource resource:tag Issue connected to the snowflake_tag resource

Comments

@chrisweis
Copy link

Provider Version

v0.64.0

Terraform Version

v1.4.6

Describe the bug

Somehow the order of the "allowed_values" property of a snowflake_tag resource is resulting in a repetitive modification upon "snowflake apply"

Screenshot for clarification:
image

Expected behavior

I would expect that either:

  1. It would understand that the allowed_values are identical even with a different order, or
  2. It would succeed in modifying the order of values to resolve the needed modification.

My preference would be #2 (if it doesn't harm tag associations) and #1 if tag associations would be harmed.

Code samples and commands

Please add code examples and commands that were run to cause the problem.

My code:

resource "snowflake_tag" "controller" {
  name           = "controller"
  database       = snowflake_database.DEV_DW_DB.name
  schema         = snowflake_schema.DBT_STAGING.name
  allowed_values = ["terraform","dbt","manual"]
}

Snowflake's state:

resource "snowflake_tag" "controller" {
  name           = "controller"
  database       = snowflake_database.DEV_DW_DB.name
  schema         = snowflake_schema.DBT_STAGING.name
  allowed_values = ["dbt","manual","terraform"]
}

Add any other context about the problem here.

Oddly, when I do a terraform destroy and then terraform apply it still doesn't resolve this order difference, almost as those the order is being cached somewhere (possibly in Snowflake?)

@chrisweis chrisweis added the bug Used to mark issues with provider's incorrect behavior label May 15, 2023
@culpgrant
Copy link

This is also similar to #1498

@culpgrant
Copy link

@chrisweis I do have an unrelated question but are you tagging objects based on what system is creating them? I have been thinking about doing it because I think it would be easier to identify what owns an object.

@chrisweis
Copy link
Author

chrisweis commented May 16, 2023

Hi @culpgrant yes, exactly! I also have other systems that control schema content (FiveTran, Segment, etc). I was experimenting with tags for tracking where object control originates, but I'm starting to think that Snowflake ownership is probably enough (ex: TERRAFORM_ROLE is owner of the objects it controls while DBT_ROLE is owner of other objects it controls). I'm working through the boundary between Terraform and dbt (especially for grants).

@culpgrant
Copy link

Yes interesting! I had the same idea and then decided that seeing the owner in Snowflake was enough.
I think the tags are a good idea though.

@sfc-gh-jcieslak sfc-gh-jcieslak added category:resource resource:tag Issue connected to the snowflake_tag resource labels May 20, 2024
@sfc-gh-jmichalak sfc-gh-jmichalak self-assigned this Oct 23, 2024
sfc-gh-jmichalak added a commit that referenced this issue Nov 20, 2024
<!-- Feel free to delete comments as you fill this in -->
- rework tag resource for v1
- generate asserts and models
- deprecate snowflake_tag_masking_policy_association
- extract a parser for extracting schema object identifier list
<!-- summary of changes -->

## Test Plan
<!-- detail ways in which this PR has been tested or needs to be tested
-->
* [x] acceptance tests
<!-- add more below if you think they are relevant -->
* [ ] …

## References
<!-- issues documentation links, etc  -->
https://docs.snowflake.com/en/sql-reference/sql/create-tag

#1806

#1443

#1394

## TODO
- tag data source
- tag association resource
- asserting that ALTER MASKING POLICY [ IF EXISTS ] <name> SET TAG
doesn't alter the tag and vice-versa
- we already unset masking policies from the tags on the tag part, but
we're missing this on masking policies part - add acc tests, too
@sfc-gh-jmichalak
Copy link
Collaborator

Hi @chrisweis @culpgrant 👋

We've just released v0.99.0 (release, migration guide) in which we reworked tags. This issue should be fixed. Please upgrade to this version and let us know if you have any issues.

@sfc-gh-jmichalak
Copy link
Collaborator

Closing due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Used to mark issues with provider's incorrect behavior category:resource resource:tag Issue connected to the snowflake_tag resource
Projects
None yet
Development

No branches or pull requests

4 participants