-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add support for GPU redundancy to Cloud Run v2 job #14519
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
Conversation
Hello! I am a robot. Tests will require approval from a repository maintainer to run. Googlers: For automatic test runs see go/terraform-auto-test-runs. @ScottSuarez, 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.
|
Tests analyticsTotal tests: 81 Click here to see the affected service packages
Found 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
@modular-magician reassign-reviewer melinath Reassigning since @c2thorn is OOO |
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.
Note: it won't be possible for users to unset this field once set, since the provider can't generally tell the difference between false
and unset
. https://googlecloudplatform.github.io/magic-modules/develop/diffs/#default has some more information about this.
Just to double-check, would it be possible to not use default_from_api? That is, any chance this isn't a complex default?
There's a default value currently set from API side. We are going to remove that default value. In order to do that, we need to support TF. In that case, is it ok to not use default_from_api at this point? Or is it better to implement it with default_from_api now and remove it later when we remove the default value from API side? |
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.
default_from_api doesn't work well with boolean fields because it's impossible to set the value to false
once it's been set to true
one time.
In general, default_value
is preferred. However, that can also cause problems if the API has a different default than what's in Terraform, or if the API has a complex default (different values depending on specific circumstances) when no value is set.
If "no default" means that the field will default to false
then you don't need default_from_api or default_value - the default default is false
. You can just make the field optional.
Relatedly: please make sure there's an update test that tries to set this field from true to false/unset so that we can make sure that it behaves properly.
At this moment, it defaults to
At this moment, API would throw an error is this field is set to |
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.
|
Tests analyticsTotal tests: 81 Click here to see the affected service packages
View the build log |
Ran into a problem where this didn't work properly without an @ symbol even though the @ symbol is optional: #14519 (comment) We should just make the `-er` optional instead of allowing arbitrary content there.
Done |
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.
|
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.
looks like you need to add the new field to https://github.com/GoogleCloudPlatform/magic-modules/blob/main/mmv1/third_party/tgc/tests/data/example_cloud_run_v2_job.json as well (right after maxRetries should be fine) - false should be fine as a value even though the API won't allow it currently.
Tests analyticsTotal tests: 81 Click here to see the affected service packages
Found 22 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
What does https://github.com/GoogleCloudPlatform/magic-modules/blob/main/mmv1/third_party/tgc/tests/data/example_cloud_run_v2_job.json do? Does it to be a valid example? The field is not allowed if GPU resource is not configured. Wondering whether I need to configure this field as well as the GPU resource. |
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.
It's for testing our ability to convert from Terraform -> CAI. It doesn't necessarily need to be something that is "valid". We're also working on moving to a new system for running these tests that will automatically pull CAI assets based on our nightly test runs and compare it to the test configs that created it, so this file will eventually go away. I think just making the easy change should be fine.
attn @zli82016 in case you have a different take.
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.
|
Tests analyticsTotal tests: 81 Click here to see the affected service packages
View the build log |
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.
|
Tests analyticsTotal tests: 81 Click here to see the affected service packages
View the build log |
Merging since @paridhishah18 approved an earlier version and it hasn't changed substantially since then. |
3cb9d50
Adds support for GPU redundancy to Cloud Run v2 job.
Release Note Template for Downstream PRs (will be copied)
See Write release notes for guidance.