Resource monitor timestamps are always considered to have changed, preventing second `terraform apply` #1624

mpbarlow · 2023-03-16T14:49:13Z

Provider Version

0.58.2

Terraform Version

1.3.9

Describe the bug

There are actually two issues here, though one is comparatively minor.

The main issue:

Creating a resource monitor with either the start or end timestamp in the format YYYY-MM-DD HH:mm works when the monitor is first created, but on subsequent runs of terraform apply, those timestamps are picked up as a change from YYYY-MM-DDTHH:mm-HH:mm. It appears that the provider is then trying to set the timestamp but not the frequency, triggering the error "Must specify frequency and start time together." The only workaround I've found for this is to taint the resource monitor each time, to force it to be recreated.

Setting the extended YYYY-MM-DDTHH:mm-HH:mm timestamp for an existing monitor triggers the same error, and that format is not recognised for new monitors either.

The second issue, which I discovered by accident, is that the above error is also displayed if creating a monitor with an empty notify_users attribute. This is not the end of the world, but is quite confusing.

Expected behavior

The timestamp is not considered a modification unless it has actually changed
Modifications to the timestamp are permitted without tainting the resource, as they are currently not even if you do change the the start_timestamp
An empty set is permitted for notify_users or the error message returned correctly identifies that the empty set is the problem

Code samples and commands

resource "snowflake_resource_monitor" "monitor" {
  name = "MONITOR"
  credit_quota = 100
  frequency = "DAILY"
  start_timestamp = "2023-03-20 00:00"
  notify_triggers = [40]
  suspend_triggers = [50]
  suspend_immediate_triggers = [90]
  notify_users = ["johnsmith"]
}

# This works
terraform apply

# This does not
terraform apply

Additional context

N/A

The text was updated successfully, but these errors were encountered:

bbelescot · 2023-03-28T07:28:38Z

Any updates on this? Impacted as well. Thank you!

curtisq · 2023-04-06T17:51:19Z

Another ➕ for this. This makes it really annoying to manage resource monitors with this provider.

rasmus-kristensen · 2023-04-25T10:39:15Z

I just hit this exact same issue thinking I had made a mistake.
Provider version 0.60.0

Bob-Jia-catalina · 2023-04-27T02:50:23Z

Hi I ran into the same issue today, Resource Monitor 'start_timestamp' is always considered 'changed' whenever 'terraform plan' or 'terraform apply'.

I can think of two approaches, what do you guys think?

Snowflake to allow past start_timestamp : maybe Snowflake could throw a warning instead of blocking? "your start_timestamp is in the past, Snowflake will not update Resource Monitor"
Terraform-Snowflake Provider to add some special workaround just for start_timestamp, e.g. "if start_timestamp in .tf is in the past, then pretend .tf does not have start_timestamp at all "

Bob-Jia-catalina · 2023-04-27T02:58:44Z

Hi I ran into the same issue today, Resource Monitor 'start_timestamp' is always considered 'changed' whenever 'terraform plan' or 'terraform apply'.

I can think of two approaches, what do you guys think?

Snowflake to allow past start_timestamp : maybe Snowflake could throw a warning instead of blocking? "your start_timestamp is in the past, Snowflake will not update Resource Monitor"

Terraform-Snowflake Provider to add some special workaround just for start_timestamp, e.g. "if start_timestamp in .tf is in the past, then pretend .tf does not have start_timestamp at all "

Thank you @tekumara! I didn't know Terraform has this 'lifecycle -> ignore_changes' config
#612 (comment)

rasmus-kristensen · 2023-04-27T06:27:34Z

Hi I ran into the same issue today, Resource Monitor 'start_timestamp' is always considered 'changed' whenever 'terraform plan' or 'terraform apply'.
I can think of two approaches, what do you guys think?

Snowflake to allow past start_timestamp : maybe Snowflake could throw a warning instead of blocking? "your start_timestamp is in the past, Snowflake will not update Resource Monitor"

Terraform-Snowflake Provider to add some special workaround just for start_timestamp, e.g. "if start_timestamp in .tf is in the past, then pretend .tf does not have start_timestamp at all "

Thank you @tekumara! I didn't know Terraform has this 'lifecycle -> ignore_changes' config #612 (comment)

Lifecycle is useful right here and now as a workaround, but long time it's not useful at all, what if we wanted to change the start date of the period i.e. instead of running monthly 1st to 1st now we run 15th to 15th, that wouldn't be possible at the moment without actually recreating the monitors.

luisNicolasB · 2023-06-21T01:46:58Z

Provider Version

0.66.2

Terraform Version

0.13.6

Is there any news about this problem, I am facing the same problem:

Error: error updating resource monitor AIRFLOW_USAGE_MONITOR
090259 (42601): Must specify frequency and start time together.

on airflow_usage_monitor.tf line 6, in resource "snowflake_resource_monitor" "usage_monitor":
6: resource "snowflake_resource_monitor" "usage_monitor" {

jacobcbeaudin · 2023-07-19T00:28:47Z

Provider Version

0.68.1

Terraform Version

1.4.6

I am also impacted by this.

│ Error: error creating resource monitor foo err = 090263 (42601): The specified Start time has already passed.
│
│   with module.snowflake.snowflake_resource_monitor.monitor["foo"],
│   on ../../modules/snowflake/account/resource-monitors.tf line 1, in resource "snowflake_resource_monitor" "monitor":
│    1: resource "snowflake_resource_monitor" "monitor" {
│
╵
╷
│ Error: error creating resource monitor bar err = 090263 (42601): The specified Start time has already passed.
│
│   with module.snowflake.snowflake_resource_monitor.monitor["bar"],
│   on ../../modules/snowflake/account/resource-monitors.tf line 1, in resource "snowflake_resource_monitor" "monitor":
│    1: resource "snowflake_resource_monitor" "monitor" {
│
╵
╷
│ Error: error creating resource monitor bat err = 090263 (42601): The specified Start time has already passed.
│
│   with module.snowflake.snowflake_resource_monitor.monitor["bat"],
│   on ../../modules/snowflake/account/resource-monitors.tf line 1, in resource "snowflake_resource_monitor" "monitor":
│    1: resource "snowflake_resource_monitor" "monitor" {
│
╵
╷
│ Error: error creating resource monitor baz err = 090263 (42601): The specified Start time has already passed.
│
│   with module.snowflake.snowflake_resource_monitor.monitor["baz"],
│   on ../../modules/snowflake/account/resource-monitors.tf line 1, in resource "snowflake_resource_monitor" "monitor":
│    1: resource "snowflake_resource_monitor" "monitor" {
│
╵

jfreidkes · 2023-07-19T14:01:27Z

Same problem here with these providers:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "3.66.1"
    }
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "~> 0.61"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "2.3.2"
    }
  }
  required_version = ">= 0.14"
}

sfc-gh-jcieslak · 2024-09-05T12:36:34Z

Hello 👋
Please refer to this response - #1175 (comment). I'll let you know whenever the updated resource is available.

## 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)

sfc-gh-jcieslak · 2024-09-20T09:54:07Z

Hey 👋
The new and refactored resource monitor was released yesterday in version 0.96.0 of the provider. Please migrate with migration guide and let me know if the issue has been resolved so we could close the ticket. Thanks in advance 🙏.

mpbarlow · 2024-09-20T10:07:44Z

Hi

Thanks for getting back to me. Unfortunately, since I opened this issue, the project it was part of was spun out into a separate company, and that company has now gone out of business (not because of this bug don’t worry). So I’m not able to verify I’m afraid.

However sounds like a few other people had the same issue so perhaps they can verify.

Cheers

sfc-gh-jcieslak · 2024-10-15T15:26:18Z

Closing due to long inactivity, they. If anyone thinks the problem is still not resolved, please create another issue.

tamas-paulik · 2024-11-06T09:32:32Z

Hey,
I am using the following provider version and still have issue with the time format. My challenge is that I want to run terraform both locally and from CICD and the format is detected somwhow differently therefore it would be very helpful if the different time formats would be detected as the same.

Provider:

required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.97.0"
    }
  }

terraform plan output:

  # module.snowflake.snowflake_resource_monitor.workload["pran_transforming_xs"] will be updated in-place
  ~ resource "snowflake_resource_monitor" "workload" {
        id                        = "PRAN_TRANSFORMING_X_SMALL_MONTHLY"
        name                      = "PRAN_TRANSFORMING_X_SMALL_MONTHLY"
      ~ start_timestamp           = "2024-10-01T02:00:00+02:00" -> "2024-10-01 00:00"
        # (8 unchanged attributes hidden)
    }

I think I will need to ignore the changes on this parameter that is not ideal:
lifecycle { ignore_changes = [ start_timestamp ] }

sfc-gh-jcieslak · 2024-11-06T12:50:31Z

Hey @tamas-paulik
Please create another issue with this description. We'll fix this as a separate task. By a quick search, I think that the timezone session parameter may be different for the CI machine and your local one causing different timestamps to be returned. The workaround or fix for this problem would be to set this parameter in the provider configuration (session_paramters field) or if that doesn't work, try to set it on the user or account level.

mpbarlow added the bug Used to mark issues with provider's incorrect behavior label Mar 16, 2023

mpbarlow changed the title ~~Resource monitor timestamps are always considered to have changed, prevent second terraform apply~~ Resource monitor timestamps are always considered to have changed, preventing second terraform apply Mar 16, 2023

RichBarnes mentioned this issue Nov 24, 2023

fix: for 1624 resource monitor timestamps are always considered to have changed #2214

Merged

3 tasks

sfc-gh-jcieslak added category:resource resource:resource_monitor Issue connected to the snowflake_resource_monitor resource labels May 20, 2024

sfc-gh-jcieslak self-assigned this Sep 5, 2024

sfc-gh-jcieslak mentioned this issue Sep 9, 2024

feat: Resource monitor v1 readiness #3052

Merged

sfc-gh-jcieslak closed this as completed Oct 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Resource monitor timestamps are always considered to have changed, preventing second `terraform apply` #1624

Resource monitor timestamps are always considered to have changed, preventing second `terraform apply` #1624

mpbarlow commented Mar 16, 2023

bbelescot commented Mar 28, 2023 •

edited

Loading

curtisq commented Apr 6, 2023

rasmus-kristensen commented Apr 25, 2023 •

edited

Loading

Bob-Jia-catalina commented Apr 27, 2023

Bob-Jia-catalina commented Apr 27, 2023

rasmus-kristensen commented Apr 27, 2023

luisNicolasB commented Jun 21, 2023

jacobcbeaudin commented Jul 19, 2023 •

edited

Loading

jfreidkes commented Jul 19, 2023

sfc-gh-jcieslak commented Sep 5, 2024

sfc-gh-jcieslak commented Sep 20, 2024

mpbarlow commented Sep 20, 2024 •

edited

Loading

sfc-gh-jcieslak commented Oct 15, 2024

tamas-paulik commented Nov 6, 2024

sfc-gh-jcieslak commented Nov 6, 2024 •

edited

Loading

Resource monitor timestamps are always considered to have changed, preventing second terraform apply #1624

Resource monitor timestamps are always considered to have changed, preventing second terraform apply #1624

Comments

mpbarlow commented Mar 16, 2023

bbelescot commented Mar 28, 2023 • edited Loading

curtisq commented Apr 6, 2023

rasmus-kristensen commented Apr 25, 2023 • edited Loading

Bob-Jia-catalina commented Apr 27, 2023

Bob-Jia-catalina commented Apr 27, 2023

rasmus-kristensen commented Apr 27, 2023

luisNicolasB commented Jun 21, 2023

jacobcbeaudin commented Jul 19, 2023 • edited Loading

jfreidkes commented Jul 19, 2023

sfc-gh-jcieslak commented Sep 5, 2024

sfc-gh-jcieslak commented Sep 20, 2024

mpbarlow commented Sep 20, 2024 • edited Loading

sfc-gh-jcieslak commented Oct 15, 2024

tamas-paulik commented Nov 6, 2024

sfc-gh-jcieslak commented Nov 6, 2024 • edited Loading

Resource monitor timestamps are always considered to have changed, preventing second `terraform apply` #1624

Resource monitor timestamps are always considered to have changed, preventing second `terraform apply` #1624

bbelescot commented Mar 28, 2023 •

edited

Loading

rasmus-kristensen commented Apr 25, 2023 •

edited

Loading

jacobcbeaudin commented Jul 19, 2023 •

edited

Loading

mpbarlow commented Sep 20, 2024 •

edited

Loading

sfc-gh-jcieslak commented Nov 6, 2024 •

edited

Loading