Closed tempus-omarsalka closed 1 month ago
Hi,
We were debugging exactly the same issue yesterday. Our observation is that this is most likely to due to empty field returned in the describe cluster action at the end of the provider spawning process :
"securityConfig": {},
which is then being destructured https://github.com/hashicorp/terraform-provider-google/blob/v6.0.1/google/services/dataproc/resource_dataproc_cluster.go#L2884
Possibly this might have something to do with some recent (not verified though) addition of the field identityConfig
(dataproc REST API) that is not mentioned currently anywhere in the provider itself.
Hi,
Any suggestions on how to resolve this issue or work around it?
Thanks, the logging and analysis are extremely helpful. Agreed that the issue appears to be a nil kerberosConfig
, which could be caused by an empty securityConfig
. This code has been untouched for ~5 years, so I would suspect an API change is the culprit (new identityConfig
field like @piotrdziuba mentioned is very plausible, since previously we had kerberosConfig
marked as required). We probably need a new nil check to resolve.
For workarounds, it would appear we need the kerberosConfig
field to be populated with something to avoid the panic, which I expect is not possible for configs that don't use it or securityConfig
at all. I don't think ignore_changes
will help either, because of where this call is being made. Rolling back the change at the API level (or fixing forward by not returning {}
) could be the only option, so we will check with the service team about options there.
hi guys this seems to be a google issue
Additional note: we are seeing a large number of dataproc tests failing with this same panic, which started last night. This includes even very simple tests like TestAccDataprocCluster_basic
.
I haven't identified an obvious change that would have caused this yet, but it looks to me like identityConfig
has been around for a while. However, there was another undocumented field that was added to securityConfig
and could be responsible.
Note: seeing some evidence of these panics as early as Aug 28
Update: The service team has been actively working on this from the API side.
Hey @roaks3 could you share an estimate when this might get resolved?
The API changes were rolled back on Friday, so this should be resolved now. Moving forward, we will be working with the service team to ensure that the provider is ready to handle the change before it is rolled out again.
@estol could you confirm if you are still seeing any issues?
@roaks3 seems to be working, thank you.
Yup working for me too, thanks!
For the service team: https://github.com/GoogleCloudPlatform/magic-modules/pull/11592 aims to resolve the actual error on the client-side, which in addition to better testing, should ensure that this doesn't surface in future rollouts.
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Community Note
Terraform Version & Provider Version(s)
Terraform v1.5.7 on amd64
Affected Resource(s)
google_dataproc_cluster
Terraform Configuration
We usually pull the latest version, but after this issue, we tried pinning multiple different v5 versions but to no avail.
Debug Output
This is where it gets weird. When i run terraform in regular mode, terrafrom panics and crashes, but the cluster still gets created; however, in debug mode, terraform runs successfully with no panic message or anything. I'm attaching the panic message that i'm only able to obtain on a regular run (no DEBUG):
Expected Behavior
Terraform completes cluster creation and exits successfully without crashing.
Actual Behavior
The dataproc cluster gets created but terraform panics and crashes.
Steps to reproduce
terraform apply
Important Factoids
Terraform was last able to run this without issues on Aug 27th. Error first observed this today.
References
No response
b/363256703