-
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
Allow deletion of resource_bigquery_table when it still has associated resource tags #10568
Conversation
Hello! I am a robot. Tests will require approval from a repository maintainer to run. @shuyama1, 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: Click here to see the affected service packages
|
@@ -1832,18 +1832,6 @@ func resourceBigQueryTableDelete(d *schema.ResourceData, meta interface{}) error | |||
if d.Get("deletion_protection").(bool) { | |||
return fmt.Errorf("cannot destroy table %v without setting deletion_protection=false and running `terraform apply`", d.Id()) | |||
} | |||
<% unless version == 'ga' -%> | |||
if v, ok := d.GetOk("resource_tags"); ok { |
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.
I think this is a breaking change that should be avoided a minor release. This is Changing resource deletion behavior
in https://googlecloudplatform.github.io/magic-modules/develop/breaking-changes/breaking-changes/#resource-level-breaking-changes.
We have a couple of options:
- wait until the next major release, which is expected in a couple of months
- introduce a virtual field to force delete the resource even when resource_tags are present and default it to false.
Please let me know your thoughts and if you have any questions. Thanks!
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.
Would the combination of the points below make it eligible for a minor version release?
- Feature was very newly added (released on 4/22)
- Feature is in the beta provider
- The new deletion behavior is more permissive instead of more restrictive
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.
@wj-chen Thanks for the quick response.
- Feature was very newly added (released on 4/22)
- Feature is in the beta provider
The beta provider is also a stable surface that does not allow breaking changes outside of major releases. See go/terraform-launch-stages#google-beta
- The new deletion behavior is more permissive instead of more restrictive
I'd still think it's breaking since it's changing the default deletion behavior and I'm a bit hesitant about changing it directly in a minor. However, if an urgent fix is needed in a minor, we could follow https://googlecloudplatform.github.io/magic-modules/develop/breaking-changes/make-a-breaking-change/#in-minor-releases - "this change can be made if the default behavior stays the same and new behavior can be enabled with a flag", such as adding a force_delete
field, which is the option 2 I proposed in #10568 (comment). Please let me know what your thought on this approach and if it will work for your use case. Thanks!
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.
I added a virtual field allow_resource_tags_on_deletion
for this purpose and this PR is ready for review again.
Can you also describe the migration path from this to my original change? Would that be a candidate for the next major release?
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.
Will discuss internally regarding the migration path for the next major release
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.
Hi @shuyama1, I'd like to follow up on this discussion again since the submission window for the next major release is now open. We want to promote this field to the GA provider, and make the default value true
in the GA provider from the get-go if possible.
- Would it count as a breaking change if the promotion and default value update take place together? If not, we'll proceed with that since it's the most ideal. Updating the default value for the beta provider will be treated as a separate breaking change.
- Otherwise, we would most likely promote first then make a breaking change to update the default value for both providers as a follow-up. This way the GA promotion won't be blocked by the next major release timeline.
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.
@wj-chen Thank you for following up on this issue.
Our policy requires that the beta provider be a superset of the GA provider. This means the features and behaviors in GA should always be consistent with those in beta.
If we want to promote the feature to GA before changing the default in beta in 6.0.0 (as you correctly noted, this default value swap is a breaking change and must wait until the 6.0.0 major release), we need to use the current default value and update the default values for both GA and beta later in the 6.0.0 release.
Hope this answers your question and let me know if you have further questions.
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.
In this case we'll proceed with promoting the feature to GA first, then making a breaking change to change the default value for the field for both GA and beta providers in the 6.0.0 release. Thank you for the guidance!
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.
Perfect. Sounds good!
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_bigquery_table" "primary" {
allow_resource_tags_on_deletion = # value needed
}
|
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_bigquery_table" "primary" {
allow_resource_tags_on_deletion = # value needed
}
|
Tests analyticsTotal tests: Click here to see the affected service packages
|
Tests analyticsTotal tests: Click here to see the affected service packages
|
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.
|
1 similar comment
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: Click here to see the affected service packages
|
Tests analyticsTotal tests: Click here to see the affected service packages
|
if err := d.Set("allow_resource_tags_on_deletion", false); err != nil { | ||
return nil, fmt.Errorf("Error setting allow_resource_tags_on_deletion: %s", err) | ||
} |
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.
I think we may also need to mark it as beta only.
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.
Added
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: Click here to see the affected service packages
|
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.
Thanks!
Allow deletion of resource_bigquery_table when it still has associated resource tags.
Release Note Template for Downstream PRs (will be copied)