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

google_compute_resource_policy inconsistent handling of start_time #8460

Comments

@assafrahav
Copy link

assafrahav commented Feb 12, 2021

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

internal build 2021.02.03-5 (mainline @355283235)

Affected Resource(s)

  • google_compute_resource_policy

Terraform Configuration Files

resource "google_compute_resource_policy" "pd_snapshots" {
  name    = "${var.component}-snapshots"
  snapshot_schedule_policy {
    schedule {
      hourly_schedule {
        hours_in_cycle = var.snapshot_interval
        start_time     = "${local.snapshot_start}:00"
      }
    }
  }
}

Debug Output

Panic Output

Expected Behavior

Terraform applies the resource and remains stable on subsequent applications.
Alternatively, it can reject start time which isn't properly padded.
The important point is that the behavior should be consistent.

Actual Behavior

If local.snapshot_start is les than 10, then the resulting time string is h:00

The resource applies this without incident, however on subsequent diffing it interprets h:00 as being different than 0h:00 and plans to destroy&recreate the resource

Steps to Reproduce

  1. create a google_compute_resource_policy resource with a start time < 10:00 and no leading 0
  2. apply the config
  3. apply terraform a second time - it will plan to destroy the resouce

Important Factoids

References

  • #0000

b/308756082

@ghost ghost added the bug label Feb 12, 2021
@venkykuberan venkykuberan self-assigned this Feb 12, 2021
@venkykuberan
Copy link
Contributor

HH:MM is the expected format, please refer the doc https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_resource_policy#start_time

start_time - (Required) Time within the window to start the operations. It must be in format "HH:MM", where HH : [00-23] and MM : [00-00] GMT.

@assafrahav
Copy link
Author

The issue is the provider isn't enforcing that requirement, it allows specifying the input in h:00 format.
Either the provider should CONSITENTLY treat h:00 as being the same as hh:00 or it should reject the input.

Accepting the input, but then getting into a destroy&create loop is not really acceptable behavior.

@assafrahav
Copy link
Author

@venkykuberan I want to be sure you saw the last comment. I don't think it's correct to close this issue based on the current behavior of the resource.

I agree that h:00 is not in the prescribed format, but the resource needs to enforce this and thrown an error rather than enter this loop of creating & destroying.

@ghost
Copy link

ghost commented Mar 18, 2021

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@rileykarson
Copy link
Collaborator

I had this issue flagged to reopen- reopened/unlocked/unassigned so it goes back to triage. We can consider suppressing the diff or disallowing inputs that'll be changed here.

modular-magician added a commit to modular-magician/terraform-provider-google that referenced this issue Jul 28, 2023
* Enhance BigQuery table schema input validation

* skip TestAccBigQueryTable_invalidSchemas in VCR test

Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit that referenced this issue Jul 28, 2023
* Enhance BigQuery table schema input validation

* skip TestAccBigQueryTable_invalidSchemas in VCR test

Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit to modular-magician/terraform-provider-google that referenced this issue Aug 15, 2023
…hashicorp#8611)

* add google_bigquery_table to version 5 upgrade doc for hashicorp#8460

* update wording

---------

Co-authored-by: Stephen Lewis (Burrows) <[email protected]>
Signed-off-by: Modular Magician <[email protected]>
modular-magician added a commit that referenced this issue Aug 15, 2023
…15509)

* add google_bigquery_table to version 5 upgrade doc for #8460

* update wording

---------

Signed-off-by: Modular Magician <[email protected]>
Co-authored-by: Stephen Lewis (Burrows) <[email protected]>
@github-actions github-actions bot added forward/review In review; remove label to forward service/compute-instances labels Oct 25, 2023
@edwardmedia edwardmedia removed the forward/review In review; remove label to forward label Oct 30, 2023
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.