-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Upgrade to 4.34.0 breaks on node_pool_auto_config
block with google-beta
provider
#12422
Upgrade to 4.34.0 breaks on node_pool_auto_config
block with google-beta
provider
#12422
Comments
@lauraseidler can you add a config that can be used to repro the issue? |
happening to us to. Basically any cluster you provision that uses nodepool autoprovisioning or autopilot, when upgrading the provider, will have this optional dynamic block added in and trigger this. At least that's what it looks like to me. |
The provider needs to be fixed, but as a work around we added this to our GKE module:
|
also as an aside... it would be great if the resource output an attribute with the current cluster network tag.... |
@brokenjacobs @lauraseidler @philip-harvey can you provide a config that can be used to repro the issue? |
@edwardmedia as far as I can tell any GKE cluster config that doesn't explicitly set node_pool_auto_config would break since the provider trys to delete node_pool_auto_config (set to null?) and this causes the provider to fail. If you set node_pool_auto_config to {}, as in my example above, then the provider doesn't fail. In the example code I provided above we are setting node_pool_auto_config and the provider is OK with this. Below is an example of the code we are using, which includes returning the network tags. This really needs to be returned by the provider as brokenjacobs mentioned.
|
@shuyama1 can you take a look at this? |
This is becoming very impactful especially because it can cause node pools to be deleted and not created when making immutable updates to pools. |
Thanks for the feedback! I was able to reproduce this error locally and I'm working on a fix now. |
Something seems different about the process of detecting changes in the node pool. I've been working on workarounds to enable dynamically updating node pool labels, tags, and taints (recently supported by the Google API if the cluster is >= 1.23 or if the cluster is 1.22 and the node pool autoscaling is turned off). Yesterday I ran into a problem where updating the node pool configuration (labels, taints, or tags) via gcloud cli triggered the nodes in that node pool to be recreated. So I've been trying to recreate that issue today. In the process, I have seen a perm-diff where the node pool has the Here is an example output from the plan where the label and taint differences are seen, but they won't trigger Terraform to change them.
Is having the extra layer of node_pool_defaults preventing the manual changes from being detected? Or is the provider updated to support dynamically updating the labels and taints? |
With the update to 4.37.0, the same problem now happens additionally with |
The PR has not been merged and released yet. You could try to pin the provider version to 4.33.0 to prevent issues in the short term until the fix is released. The PR is targeting the next release. |
4.38.0 has been released, and the issue still persists on both Apply output:
|
Agree with @thameezb. I have the same issue on the latest release i-e |
Agree with @thameezb. I'm facing the same issue with |
The fix is released in v4.39.0. Can you try upgrading to v4.39.0 and see if the issue still occurs? |
The issue is resolved now with v4.39.0. Thanks much! |
Glad it's solved! Thanks for the update! |
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. |
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)
Terraform Configuration Files
We're using a module within a module within a module to create the cluster (
terraform-google-modules/kubernetes-engine/google//modules/safer-cluster-update-variant
) - I can try to produce a minimal example with just the resource if necessary, but I'm unsure whether it's relevant, maybe this is already enough.Debug Output
Panic Output
Expected Behavior
Plan shows that changes outside of Terraform were made:
With this change to be rolled back:
I would expect this to either succeed, or the change outside of Terraform to not happen in the first place.
Actual Behavior
Apply fails with error
Steps to Reproduce
terraform plan
terraform apply
Important Factoids
References
The text was updated successfully, but these errors were encountered: