feat: Tag association v1 readiness

MIGRATION_GUIDE.md

@@ -6,8 +6,8 @@ across different versions.
 
 > [!TIP]
 > We highly recommend upgrading the versions one by one instead of bulk upgrades.
- 
-## v0.98.0 ➞ v0.99.0
+
+## v0.99.0 ➞ v0.100.0
 
 ### snowflake_tag_association resource changes
 #### *(behavior change)* new id format
@@ -33,7 +33,17 @@ resource "snowflake_tag_association" "silver_databases" {
 }
 ```
 
-The state is migrated automatically. There is no need to adjust configuration files, unless you use resource id like `snowflake_tag_association.example.id`.
+Note that if you want to promote silver instances to gold, you can not simply change `tag_value` in `silver_warehouses`. Instead, you should merge `object_identifiers` from `silver_warehouses` and `gold_warehouses`, and use them only in `gold_warehouses`, like this (note that `silver_warehouses` resource was deleted):
+```
+resource "snowflake_tag_association" "gold_warehouses" {
+  object_identifiers = [snowflake_warehouse.w1.fully_qualified_name, snowflake_warehouse.w2.fully_qualified_name, snowflake_warehouse.w3.fully_qualified_name]
+  object_type = "WAREHOUSE"
+  tag_id      = snowflake_tag.tier.fully_qualified_name
+  tag_value   = "gold"
+}
+```
+
+The state is migrated automatically. There is no need to adjust configuration files, unless you use resource id `snowflake_tag_association.example.id` as a reference in other resources.
 
 #### *(behavior change)* changed fields
 Behavior of some fields was changed:
@@ -64,6 +74,156 @@ resource "snowflake_tag_association" "table_association" {
 
 The state is migrated automatically. Please adjust your configuration files.
 
+## v0.98.0 ➞ v0.99.0
+
+### snowflake_tasks data source changes
+
+New filtering options:
+- `with_parameters`
+- `like`
+- `in`
+- `starts_with`
+- `root_only`
+- `limit`
+
+New output fields
+- `show_output`
+- `parameters`
+
+Breaking changes:
+- `database` and `schema` are right now under `in` field
+
+Before:
+```terraform
+data "snowflake_tasks" "old_tasks" {
+  database = "<database_name>"
+  schema = "<schema_name>"
+}
+```
+After:
+```terraform
+data "snowflake_tasks" "new_tasks" {
+  in {
+    # for IN SCHEMA specify:
+    schema = "<database_name>.<schema_name>"
+
+    # for IN DATABASE specify:
+    database = "<database_name>"
+  }
+}
+```
+- `tasks` field now organizes output of show under `show_output` field and the output of show parameters under `parameters` field.
+
+Before:
+```terraform
+output "simple_output" {
+  value = data.snowflake_tasks.test.tasks[0].name
+}
+```
+After:
+```terraform
+output "simple_output" {
+  value = data.snowflake_tasks.test.tasks[0].show_output[0].name
+}
+```
+
+### snowflake_task resource changes
+New fields:
+- `config` - enables to specify JSON-formatted metadata that can be retrieved in the `sql_statement` by using [SYSTEM$GET_TASK_GRAPH_CONFIG](https://docs.snowflake.com/en/sql-reference/functions/system_get_task_graph_config).
+- `show_output` and `parameters` fields added for holding SHOW and SHOW PARAMETERS output (see [raw Snowflake output](./v1-preparations/CHANGES_BEFORE_V1.md#raw-snowflake-output)).
+- Added support for finalizer tasks with `finalize` field. It conflicts with `after` and `schedule` (see [finalizer tasks](https://docs.snowflake.com/en/user-guide/tasks-graphs#release-and-cleanup-of-task-graphs)).
+
+Changes:
+- `enabled` field changed to `started` and type changed to string with only boolean values available (see ["empty" values](./v1-preparations/CHANGES_BEFORE_V1.md#empty-values)). It is also now required field, so make sure it's explicitly set (previously it was optional with the default value set to `false`).
+- `allow_overlapping_execution` type was changed to string with only boolean values available (see ["empty" values](./v1-preparations/CHANGES_BEFORE_V1.md#empty-values)). Previously, it had the default set to `false` which will be migrated. If nothing will be set the provider will plan the change to `default` value. If you want to make sure it's turned off, set it explicitly to `false`.
+
+Before:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  enabled = true
+  # ...
+}
+```
+After:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  started = true
+  # ...
+}
+```
+- `schedule` field changed from single value to a nested object that allows for specifying either minutes or cron
+
+Before:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  schedule = "5 MINUTES"
+  # or
+  schedule = "USING CRON * * * * * UTC"
+  # ...
+}
+```
+After:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  schedule {
+    minutes = 5
+    # or
+    using_cron = "* * * * * UTC"
+  }
+  # ...
+}
+```
+- All task parameters defined in [the Snowflake documentation](https://docs.snowflake.com/en/sql-reference/parameters) added into the top-level schema and removed `session_parameters` map.
+
+Before:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  session_parameters = {
+    QUERY_TAG = "<query_tag>"
+  }
+  # ...
+}
+```
+After:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  query_tag = "<query_tag>"
+  # ...
+}
+```
+
+- `after` field type was changed from `list` to `set` and the values were changed from names to fully qualified names.
+
+Before:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  after = ["<task_name>", snowflake_task.some_task.name]
+  # ...
+}
+```
+After:
+```terraform
+resource "snowflake_task" "example" {
+  # ...
+  after = ["<database_name>.<schema_name>.<task_name>", snowflake_task.some_task.fully_qualified_name]
+  # ...
+}
+```
+
+### *(new feature)* snowflake_tags datasource
+Added a new datasource enabling querying and filtering tags. Notes:
+- all results are stored in `tags` field.
+- `like` field enables tags filtering by name.
+- `in` field enables tags filtering by `account`, `database`, `schema`, `application` and `application_package`.
+- `SHOW TAGS` output is enclosed in `show_output` field inside `tags`.
+
 ### snowflake_tag_masking_policy_association deprecation
 `snowflake_tag_masking_policy_association` is now deprecated in favor of `snowflake_tag` with a new `masking_policy` field. It will be removed with the v1 release. Please adjust your configuration files.
 

docs/resources/authentication_policy.md

@@ -5,7 +5,8 @@ description: |-
   Resource used to manage authentication policy objects. For more information, check authentication policy documentation https://docs.snowflake.com/en/sql-reference/sql/create-authentication-policy.
 ---
 
--> **Note** According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-authentication-policy#usage-notes), an authentication policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
+> [!WARNING]
+> According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-authentication-policy#usage-notes), an authentication policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
 
 # snowflake_authentication_policy (Resource)
 

docs/resources/masking_policy.md

@@ -7,7 +7,8 @@ description: |-
 
 !> **V1 release candidate** This resource was reworked and is a release candidate for the V1. We do not expect significant changes in it before the V1. We will welcome any feedback and adjust the resource if needed. Any errors reported will be resolved with a higher priority. We encourage checking this resource out before the V1 release. Please follow the [migration guide](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md#v0950--v0960) to use it.
 
--> **Note** According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-masking-policy#usage-notes), a masking policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
+> [!WARNING]
+> According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-masking-policy#usage-notes), a masking policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
 
 # snowflake_masking_policy (Resource)
 

docs/resources/network_policy.md

@@ -7,7 +7,8 @@ description: |-
 
 !> **V1 release candidate** This resource was reworked and is a release candidate for the V1. We do not expect significant changes in it before the V1. We will welcome any feedback and adjust the resource if needed. Any errors reported will be resolved with a higher priority. We encourage checking this resource out before the V1 release. Please follow the [migration guide](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md#v0920--v0930) to use it.
 
--> **Note** According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-network-policy#usage-notes), a network policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
+> [!WARNING]
+> According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-network-policy#usage-notes), a network policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
 
 # snowflake_network_policy (Resource)
 

docs/resources/password_policy.md

@@ -5,7 +5,8 @@ description: |-
   A password policy specifies the requirements that must be met to create and reset a password to authenticate to Snowflake.
 ---
 
--> **Note** According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-password-policy#usage-notes), a password policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
+> [!WARNING]
+> According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-password-policy#usage-notes), a password policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
 
 # snowflake_password_policy (Resource)
 

docs/resources/row_access_policy.md

@@ -7,7 +7,8 @@ description: |-
 
 !> **V1 release candidate** This resource was reworked and is a release candidate for the V1. We do not expect significant changes in it before the V1. We will welcome any feedback and adjust the resource if needed. Any errors reported will be resolved with a higher priority. We encourage checking this resource out before the V1 release. Please follow the [migration guide](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md#v0950--v0960) to use it.
 
--> **Note** According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-row-access-policy#usage-notes), a row access policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
+> [!WARNING]
+> According to Snowflake [docs](https://docs.snowflake.com/en/sql-reference/sql/drop-row-access-policy#usage-notes), a row access policy cannot be dropped successfully if it is currently assigned to another object. Currently, the provider does not unassign such objects automatically. Before dropping the resource, list the assigned objects with `SELECT * from table(information_schema.policy_references(policy_name=>'<string>'));` and unassign them manually with `ALTER ...` or with updated Terraform configuration, if possible.
 
 # snowflake_row_access_policy (Resource)
 

docs/resources/tag_association.md

@@ -9,6 +9,8 @@ description: |-
 
 -> **Note** For `ACCOUNT` object type, only identifiers with organization name are supported. See [account identifier docs](https://docs.snowflake.com/en/user-guide/admin-account-identifier#format-1-preferred-account-name-in-your-organization) for more details.
 
+-> **Note** Tag association resource ID has the following format: `"TAG_DATABASE"."TAG_SCHEMA"."TAG_NAME"|TAG_VALUE|OBJECT_TYPE`. This means that a tuple of tag ID, tag value and object type should be unique across the resources. If you want to specify this combination for more than one object, you should use only one `tag_association` resource with specified `object_identifiers` set.
+
 # snowflake_tag_association (Resource)
 
 Resource used to manage tag associations. For more information, check [object tagging documentation](https://docs.snowflake.com/en/user-guide/object-tagging).