-
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
google_bigquery_dataset - infinite diff if access
is specified with non-legacy IAM roles
#8370
Comments
This is a known behavior, You can change your config to use Basic role
|
Hey @venkykuberan, I understand that the API converts predefined roles to their basic counterparts. I'm asking if it's possible to avoid a diff in the case where the predefined role on the config already matches the basic role in the live state, since there isn't actually a semantic difference in this case. |
@rileykarson what are you thoughts ? |
It's currently expected behaviour that only legacy roles can be specified: GoogleCloudPlatform/magic-modules#4191 I could see a case for allowing it, but at the moment that would be an enhancement and not a bug. |
Gotcha I see, is there anything I need to do here to change this to an enhancement and not a bug then? Also, I would not consider this high priority, though it has caused confusion for the user since we didn't have a warning like GoogleCloudPlatform/magic-modules#4191 (and even if we did, I'm sure users will still run into the issue anyway since the underlying API does accept the new roles). We can add a similar warning on our side in the meantime though. |
Hi, Here is the resource: terraform {
required_version = "1.3.6"
required_providers {
google = "4.48.0"
}
}
resource "google_bigquery_dataset" "self_service" {
project = var.self_service_project
dataset_id = "${var.tenant}_${var.stage}_self_service"
friendly_name = "Views for ${var.tenant} agent tool"
description = "Views for ${var.tenant} agent tool"
location = var.dataset_location
default_table_expiration_ms = null
delete_contents_on_destroy = false
labels = null
access {
role = "READER"
group_by_email = "gcp-${var.self_service_project}-${var.tenant}${var.stage}Agent@email.com"
}
access {
role = "OWNER"
special_group = "projectOwners"
}
} and here is the plan: ~ resource "google_bigquery_dataset" "self_service" {
id = "projects/<project-id>/datasets/test_pre_self_service"
# (13 unchanged attributes hidden)
- access {
- role = "OWNER" -> null
- special_group = "projectOwners" -> null
}
+ access {
+ group_by_email = "gcp-testpreAgent@email.com"
+ role = "READER"
}
- access {
- group_by_email = "gcp-testpreAgent@email.com" -> null
- role = "READER" -> null
}
+ access {
+ role = "OWNER"
+ special_group = "projectOwners"
}
} Any help will be highly appreciated. |
…orp#8370) Signed-off-by: Modular Magician <magic-modules@google.com>
This issue still persists, even without making any changes to the resources there is a |
Community Note
modular-magician
user, 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)
google_bigquery_dataset
Terraform Configuration Files
Debug Output
https://gist.github.com/jcanseco/f51d951db4a30378a0183cef0d21de08
Expected Behavior
Running
terraform plan
afterterraform apply
should return an empty diff.Actual Behavior
Running
terraform plan
afterterraform apply
returned a non-empty diff:Steps to Reproduce
terraform apply
the above configurationterraform plan
the above configurationIt seems the issue is that Terraform's set hashing function for
access
doesn't account for the fact the BigQuery API only returns legacy IAM roles (e.g.OWNER
) even if users setaccess[].role
to modern IAM roles (e.g.roles/bigquery.dataOwner
). See the API documentation foraccess[].role
for more info.So it seems like one idea for a fix is to implement a set hashing function that accounts for the conversion done by the BigQuery API.
References
b/359595039
The text was updated successfully, but these errors were encountered: