google_container_node_pool: Allow updates to network tags

[jcanseco]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

It seems GKE recently supported the ability to update node pools' network tags (the node_config.tags field of google_container_node_pool and google_container_cluster).

We'd like to request this ability be supported on Terraform as well.

New or Affected Resource(s)

• google_container_node_pool
• google_container_cluster

References

• b/216689421

[krx252525]

My understanding is that me reporting this problem resulted in this issue getting created... We don't use the Google terraform provider directly but via KCC which is related to this codebase.

I've had good luck following the docs describing how to Update Exiting NodePools. I can update network tags on existing nodepools following those docs. It is however tedious taking into account the number of clusters and nodepools we're running besides the hoops required to get necessary IAM permissions.

The above being the initial driver since then I've seen some weird behaviour (circa ~5 minutes ago) where the order of ContainerNodePool.spec.nodeConfig.tags[] (excuse the KRM speak) is seemingly significant.

The significance of that behaviour has implications (read: inconveniences) when merely refactoring these resources. We have until now mostly hand-crafted these resources and now finally automating their generation. But since the order of ContainerNodePool.spec.nodeConfig.tags is significant it is a fair bit more difficult than modifying structure, no logical change, in git.

So for example this behaves:

spec:
  nodeConfig:
    tags:
     - tagA
     - tagB  

Different to:

spec:
  nodeConfig:
    tags:
     - tagB
     - tagA   

I'm curious if this is just pilot error or if it is expected that a change in the order would result in this behaviour?

[rileykarson]

I can't speak to Config Connector behaviour in any detail, @jcanseco if you've got any insight!

Marking as upstream as the API's not all the way there. GoogleCloudPlatform/magic-modules#5671 (comment)

[jcanseco]

Hello folks! Apologies for the late response.

My understanding is that me reporting this problem resulted in this issue getting created... We don't use the Google terraform provider directly but via KCC which is related to this codebase.

@keir-rex Yep I believe this request did come from you :) ContainerCluster and ContainerNodePool are two of KCC's TF-based resources, so we have to support the requested behavior on TF first before being able to support it on KCC (hence the existence of this GitHub issue).

I've seen some weird behaviour (circa ~5 minutes ago) where the order of ContainerNodePool.spec.nodeConfig.tags[] (excuse the KRM speak) is seemingly significant.

Gotcha. It isn't immediatiely obvious to me right now what's going on, so can I ask you to open an issue in https://github.com/googleCloudPlatform/k8s-config-connector/ so we can investigate further? In particular, the following details would be greatly helpful: what the problem is, how to reproduce it, and how this impacts you.

(Alternatively, if you don't want to file a public GitHub issue, you can also reach out to your customer support and let them know of the problem so we can investigate).

[github-actions]

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.