DLP - google_data_loss_prevention_stored_info_type - group_indexes (regex) update not working #8329
Assignees
Labels
Comments
Google Cloud SDK VersionGoogle Cloud SDK 325.0.0 |
|
@brodseba is the resource creation failed or are you getting warnings ? can you please add a little more detail about the issue you are facing. |
|
@venkykuberan I'm not getting any warning. Terraform tell me the change have been made successfully. But if I check the actual resource in GCP, it's not change. I'm guessing if the resource was not already created, I may see an error but in this case, the resource was already created, I only tried to modify it. If I reapply the same code, Terraform will detect the resource is out of sync and will plan the same change again (still without success.) It's only when I check using TF_LOG=DEBUG that I saw the error message. For the complete debug log, this is a production infrastructure, so I don't think I can give it to you. But I will create a test code for you (with complete logs) if you need it. |
|
Terraform v0.14.5
Here an example: provider "google" {
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = ">= 3.5"
}
random = {
source = "hashicorp/random"
version = ">= 2.0"
}
}
required_version = ">= 0.13"
}
resource "google_data_loss_prevention_stored_info_type" "MY_CUSTOM_INFO_TYPE" {
description = "MY_CUSTOM_INFO_TYPE"
display_name = "MY_CUSTOM_INFO_TYPE"
parent = "projects/test-cyber-metrie/locations/global"
regex {
pattern = "(?:some=)(thing)"
group_indexes = [1]
}
}And here the debug logs: |
|
@venkykuberan Creating a NEW resource with group_indexes work. Maybe a error with the PATCH request from the REST/gRPC? I create a custom info_type (MY_CUSTOM_INFO_TYPE_2) without an group_indexes. Apply using terraform. Then I added the group_indexes, re-apply with terraform and got the issue. |
|
@venkykuberan |
brodseba
changed the title
|
I updated the issue description. |
|
@brodseba i see the issue, we will fix it. Thanks for filing the issue. |
4 tasks
|
@brodseba would triggering recreation on the stored_info_type work in this situation? That's the easiest solution and shouldn't cause any issues if I understand the stored info type resource correctly as there is no state associated with it that gets lost during recreation |
|
@slevenick |
|
I think the short term solution here is to force recreation of the resource when this field is updated. That will solve the bug that is happening here. Longer term we should fully implement the PATCH call to allow updates on this field, but this is complicated right now because we only want to allow a subset of updates. Updating from a Full support for update would be triaged as a feature request rather than a bug, so I'll file a new issue for that |
This was referenced Feb 10, 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! |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Community Note
modular-magicianuser, 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 tohashibot, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Expected Behavior
Update a google_data_loss_prevention_stored_info_type resource to add a group_indexes.
Actual Behavior
Resource not updated.
Steps to Reproduce
Important Factoids
Resource creation with group_indexes work, but not update.
References
https://cloud.google.com/dlp/docs/reference/rpc/google.privacy.dlp.v2#google.privacy.dlp.v2.CustomInfoType.Regex
The text was updated successfully, but these errors were encountered: