-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add host_error_timeout_seconds
field to compute_instance
on beta provider
#11652
Add host_error_timeout_seconds
field to compute_instance
on beta provider
#11652
Conversation
Hello! I am a robot. Tests will require approval from a repository maintainer to run. @NickElliot, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look. You can help make sure that review is quick by doing a self-review and by running impacted tests locally. |
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
Missing test reportYour PR includes resource fields which are not covered by any test. Resource: resource "google_compute_instance" "primary" {
scheduling {
maintenance_interval = # value needed
}
}
Resource: resource "google_compute_instance_from_machine_image" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
maintenance_interval = # value needed
min_node_cpus = # value needed
preemptible = # value needed
}
}
Resource: resource "google_compute_instance_from_template" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
maintenance_interval = # value needed
min_node_cpus = # value needed
on_host_maintenance = # value needed
preemptible = # value needed
}
}
Resource: resource "google_compute_region_instance_template" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
}
}
|
Tests analyticsTotal tests: 1000 Click here to see the affected service packages
Action takenFound 2 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the API receiving an improper value aborts the entire operation, then it should be fine to allow the API to handle it. The concern with Terraform validation would be adding a maintenance cost should the values involved change. The reason to have it handled in Terraform is if the error could result in a potential permadiff or mismatch in state between local and remote.
mmv1/third_party/terraform/website/docs/d/compute_instance.html.markdown
Outdated
Show resolved
Hide resolved
mmv1/third_party/terraform/website/docs/d/compute_instance_template.html.markdown
Outdated
Show resolved
Hide resolved
mmv1/third_party/terraform/website/docs/d/compute_region_instance_template.html.markdown
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
misclick
…l.markdown Co-authored-by: Nick Elliot <nickelliot@google.com>
…plate.html.markdown Co-authored-by: Nick Elliot <nickelliot@google.com>
…nce_template.html.markdown Co-authored-by: Nick Elliot <nickelliot@google.com>
Just to clarify. Yes the error-handling is fully supported on the API side. Any incorrect input will fail the apply so there is no risk of having a permadiff. |
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
Missing test reportYour PR includes resource fields which are not covered by any test. Resource: resource "google_compute_instance" "primary" {
scheduling {
maintenance_interval = # value needed
}
}
Resource: resource "google_compute_instance_from_machine_image" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
maintenance_interval = # value needed
min_node_cpus = # value needed
preemptible = # value needed
}
}
Resource: resource "google_compute_instance_from_template" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
maintenance_interval = # value needed
min_node_cpus = # value needed
on_host_maintenance = # value needed
preemptible = # value needed
}
}
Resource: resource "google_compute_region_instance_template" "primary" {
scheduling {
host_error_timeout_seconds = # value needed
}
}
|
Tests analyticsTotal tests: 1007 Click here to see the affected service packages
View the build log |
@NickElliot This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to ask one last question: for the "default behavior" is host_error_timeout_seconds
still being returned in GET requests, or is the field not returned at all?
While testing your question i found a bug that probably has something to do with the additional function for Diff on |
Ok, this isn't specific to this field. Every field that isn't a ForceNew in the Scheduling block will be impacted by this. Use
Do you want me to fix it in this PR? Or create a separate one. Because this field is fully functional and only held back by a block-wide bug Most likely this will require a CustomizeDiff |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given it's part of behavior for the full block I think it's fine to approve as is, and introduce a new PR for fixing the wider bug. Thanks for the contribution!
…provider (GoogleCloudPlatform#11652) Co-authored-by: Nick Elliot <nickelliot@google.com>
…provider (GoogleCloudPlatform#11652) Co-authored-by: Nick Elliot <nickelliot@google.com>
…provider (GoogleCloudPlatform#11652) Co-authored-by: Nick Elliot <nickelliot@google.com>
-Added field to
google_compute_instance
andgoogle_compute_instance_template
-Added tests
-Added doc changes
-Added data_source support
Do you want me to introduce plan-time validation of this field or should the API handle errors on this field?
Release Note Template for Downstream PRs (will be copied)