-
Notifications
You must be signed in to change notification settings - Fork 420
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
Resource monitor creation fails, yet objects are created. #1754
Comments
I have yet another issue with resource monitor.
Timestamp changes -> |
Hey 👋 |
@sfc-gh-jcieslak I've had this parked for a long time, now upon revisit it seems the previous error is no longer occurring, however it does in fact wish to change the monitor on each apply as it assumes the timestamp has been changed. By specifying a resource such as the one below now creates without issues. resource "snowflake_resource_monitor" "monitor" {
name = "MONITOR"
credit_quota = 100
frequency = "MONTHLY"
start_timestamp = "${formatdate("YYYY-MM", time_offset.next_month.rfc3339)}-01 00:00 UTC"
suspend_trigger = 110
warehouses = [module.dbdp_loader_xsmall_wh.name, module.dbdp_transformer_xsmall_wh.name, module.dbdp_analyst_xsmall_wh.name]
} But upon next run it wants to change the timestamp format to However the issue @tamathew mentions is still valid after the resource has been created with the "wrong" timestamp format. Terraform will perform the following actions:
# module.snowflake.snowflake_resource_monitor.monitor will be updated in-place
~ resource "snowflake_resource_monitor" "monitor" {
id = "MONITOR"
name = "MONITOR"
~ start_timestamp = "2024-10-01T02:00:00+02:00" -> "2024-10-01T00:00:00+02:00"
# (7 unchanged attributes hidden)
}
Error: error updating resource monitor MONITOR
must specify frequency and start time together |
Yeah, I've this a lot in other issues. I handled it and the timestamps shouldn't cause those issues anymore in the upcoming version. I'll also test it with this particular case, Thank You. |
## Changes - Add ValuePresent assert to our custom assertions - Add ToConfigValues function for every model - Update Resource Monitor SDK + unit and integration tests - Update Resource Monitor Resource + acc tests - Handle issues connected to the resource monitor (mostly timestamp format difference causing infinite plan or only trigger updates causing SQL compilation error): - #1500 - #1624 - #1716 - #1754 - #1821 - #1832 - #1990 ## Next pr - Adjust examples and update migration notes - Data source (impl, tests, examples, migration notes) ## References * [CREATE RESOURCE MONITOR](https://docs.snowflake.com/en/sql-reference/sql/create-resource-monitor)
## Changes - Add ValuePresent assert to our custom assertions - Add ToConfigValues function for every model - Update Resource Monitor SDK + unit and integration tests - Update Resource Monitor Resource + acc tests - Handle issues connected to the resource monitor (mostly timestamp format difference causing infinite plan or only trigger updates causing SQL compilation error): - #1500 - #1624 - #1716 - #1754 - #1821 - #1832 - #1990 ## Next pr - Adjust examples and update migration notes - Data source (impl, tests, examples, migration notes) ## References * [CREATE RESOURCE MONITOR](https://docs.snowflake.com/en/sql-reference/sql/create-resource-monitor)
Hey 👋 |
Closing due to long inactivity. Please, create another issue if you think the problem is still not resolved. |
Provider Version
0.62.0
Terraform Version
1.4.5
Describe the bug
When attempting to create new resource monitor in snowflake the "terraform init" runs successfully and as expected however the apply fails, yet the objects are still created in snowflake.
When attempting to terraform apply again it now complains that the objects already exists and are not found in the state.
Expected behavior
terraform apply should not fails as it does actually create the objects, in version 0.61.0 this is not an issue.
Code samples and commands
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: