feat: Add google_serviceusagev2_consumer_policy resource - #18735
feat: Add google_serviceusagev2_consumer_policy resource#18735shahmedhaCorp wants to merge 11 commits into
Conversation
|
Googlers: For automatic test runs see go/terraform-auto-test-runs. @melinath, 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. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
@melinath This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
melinath
left a comment
There was a problem hiding this comment.
This is mostly just copying over the existing comments from the previous PR - I need to think about your responses there some more but there are also a couple unaddressed comments remaining
| // check dependencies if the "respect_dependencies" flag is enabled | ||
| validateDependenciesEnabled := d.Get("validate_dependencies").(bool) | ||
|
|
||
| if validateDependenciesEnabled { |
There was a problem hiding this comment.
👍 okay! makes sense. Just to double-check, do we need this to also run this on pre_create and pre_delete, since those are both technically also updates?
| description: | | ||
| (Optional) Default value is true. If true, this flag enforces dependency management within the consumer policy. When adding a new service, it verifies that all its dependencies are already present/added in the policy. Conversely, when removing a service, it ensures that no other services within the policy depend on the service to be removed. If the validation fails, a comprehensive message will be presented, outlining the missing dependencies and providing instructions on how to address the issue. | ||
| default_value: true | ||
| - name: 'check_usage_on_remove' |
There was a problem hiding this comment.
you're right; this doesn't make sense as a deletion_policy.
I find the name a little confusing; I had previously assumed that this was related to removing the resource, which is why I thought deletion_policy would make sense.
Is there a different name we could use? For example, force or ignore_validation_errors or similar? (I'd lean towards force since that's what the API flag is called.)
Also, does this need to be checked on create / delete, since those are both technically update calls?
| // | ||
| // ---------------------------------------------------------------------------- | ||
|
|
||
| package serviceusagev2 |
There was a problem hiding this comment.
Why does the operation need to be handwritten? It would be great to avoid this if possible.
There was a problem hiding this comment.
The handwritten operation (service_usage_v2_operation.go.tmpl) is necessary because this resource requires bespoke client-side verification phases and custom error handling that standard declarative OpAsync cannot accommodate.
According to the technical design (go/terraform-suv2), before and during updates, the provider must run manual Client-Side Consistency Checks, Dependency Verification (using custom traversals from ListDescendantServices), and Usage Enforcements.
These custom pre-update and post-update Go template hooks rely explicitly on custom polling/waiting utility functions (like ServiceUsageV2OperationWaitTime). If we discard this handwritten file in favor of standard declarative generation, those custom template hooks can no longer access these custom standalone polling methods, leading to undefined compiler panics and breaking the entire build and test pipelines.
There was a problem hiding this comment.
I tried switching to generating the operation code (by removing this file and adding autogen_async: true to ConsumerPolicy.yaml) and I don't see any compilation errors; ServiceUsageV2OperationWaitTime is present as expected.
The custom code here seems to be the error handling - but ServiceUsageV2OperationWaitTime already returns its error, and there aren't any retries or anything within the "wait" logic. See operation_generated.diff.txt
Could the error handling just happen one layer up in the pre_update hook? For create you can use custom_code.post_create_failure to handle the error; for update I think you should be able to use custom_code.post_update.
If this behavior is specific to this resource, that would be the best path; if you want this behavior to be consistent for every resource in the v2 service, then custom operation could make sense.
f294dc6 to
bbb69ea
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
The TeamCity Services Diff Check / teamcity-services-diff-check (pull_request) is failing due to |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes for commit 318c5ed: Diff reportYour PR generated the following diffs in downstream repositories:
Missing service labelsThe following new resources do not have corresponding service labels:
If you believe this detection to be incorrect please raise the concern with your reviewer. Googlers: This error is safe to ignore once you've completed go/fix-missing-service-labels. Test reportAnalytics
Affected Service Packages
Step 1: Replaying Mode Action takenFound 19 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
View the replaying VCR build log Step 2: Recording Mode Caution Panic occurred during VCR tests 🔴 RECORDING mode: The provider crashed with a panic. Please check the build log for details. Please fix the issue to complete your PR. View the build log @shahmedhaCorp, @melinath VCR tests complete for 318c5ed! |
yeah, those were removed in the 8.0.0 major release, but it looks like we missed removing them from the main branch. It's not related to this PR. #18774 will fix this. |


Adding new resource for service usage v2 consumer policy
b/543553096
Previous PR: #18517
Release Note Template for Downstream PRs (will be copied)