-
Notifications
You must be signed in to change notification settings - Fork 918
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
GKE Autopilot module: add network tags #1675
GKE Autopilot module: add network tags #1675
Conversation
Oh, one last thing! I do wonder if the input variable should be called |
Spotted a few references to GKE Standard clusters in the README. Fixed that and expanded Backup for GKE example section. Added a TOC as well as the README is getting longer |
Removed a reference to Standard clusters and updated the section to include a warning because the new versions of Autopilot clusters can only use Cloud DNS and it is pre-configured by default so the example in the README does not apply to them.
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.
Very nice, thanks for this. A couple areas are a bit overkill vs our traditional approach. README changes are great!
Added a |
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 :)
This PR adds support for network tags to
gke-cluster-autopilot
module.There was a
nullable
input variabletags
defined before I started but for some reason it was not used by the module.In addition to making use of the variable, I made it non-nullable and added validation as well.
Potential impact area
Estimated risk: minimal.
Feedback wanted
I'm still new to Fabric so please don't hesitate to tell me if my validation is excessive 🥲 and I will trim it.
Another question I have is about
node_pool_auto_config
block ingoogle_container_cluster
. The Terraform resource docs say it's in "beta" although I can see the corresponding JSON block not only in v1beta API but also in v1. Is it just the case of Terraform Google provider lagging behind the release cadence of the API or am I missing something more fundamental here? From a practical point of view, this module was already usinggoogle-beta
provider so it's not really an issue, I'm just curious.Lastly, I have a
FIXME
comment in the code where I had to use adynamic
block to work around a glitch in diff-ing the empty list of network tags. My understanding is that the API does allow an empty list but Terraform somehow can't cope with it and considers it to be a diff. My question is should I proceed with thedynamic
block or should I try to report this upstream into the provider so that this unnecessary empty diff does not happen?I hope this makes sense. Any other feedback is welcome as well...
Checklist
I acknowledge that I have:
terraform fmt
on all modified filestools/tfdoc.py