gke-cluster-standard: change logging configuration

[olliefr]

This PR changes how gke-cluster-standard module handles an optional logging_config argument.

The change is to use the same object-based interface to configure logging as proposed for gke-cluster-autopilot in #1625. This was requested by @juliocc.

Notes

Logging configuration is more tricky for GKE Standard clusters than it is for GKE Autopilot clusters. This is because in Autopilot, you always have system components and workloads, and the rest of the components are all optional and independent from one another. In Standard, you can have:

• no components at all (Cloud Logging integration would be turned off)
• only the system logs (a single component)
• the system logs and other components. The system logs are mandatory if something else is enabled as well.

I think I have managed to achieve the validation and code generation for all three cases outlined above. But more testing or any other feedback is welcome!

Examples and tests

I also updated the module README with two examples and added two corresponding tests to ./tests/modules/gke_cluster_standard/. I couldn't figure out how to run the full test harness, so please double check if I got this right 🥲

Changes to other components

Since this module already had an implementation for logging_config, I searched the whole CFT repo for references to this module and investigated for each match whether it should be updated. I found only a single place that required updates to its logging configuration - everything else did not mention logging configuration at all because it was relying on the default one. The default configuration did not change.

The updated blueprint is GKE Multitenant Fleet. I modelled my changes on the existing practice for handling input of type object in that module.

Feedback is welcome!

---

Checklist

I applicable, I acknowledge that I have:

• Read the contributing guide
• Ran terraform fmt on all modified files
• Regenerated the relevant README.md files using tools/tfdoc.py
• Made sure all relevant tests pass

[juliocc]

Looks great. Left just one small comment below

@olliefr I added you as contributor. You should be able to merge this once the checks finish

[juliocc]

The FAST failures are because of the variables types. Just make them match to the new type.

The module test is missing an outer list. It should look something like this:

values:
  module.cluster-1.google_container_cluster.cluster:
    logging_config:
    - enable_components: []

and

  module.cluster-1.google_container_cluster.cluster:
    logging_config:
    - enable_components:
      - APISERVER
      - CONTROLLER_MANAGER
      - SCHEDULER
      - SYSTEM_COMPONENTS
      - WORKLOADS

[olliefr]

@juliocc all done! What's the preferred way of dealing with the drift from the master branch? Is it OK to merge the master into this branch and then, if successful, merge back into master?

[juliocc]

@juliocc all done! What's the preferred way of dealing with the drift from the master branch? Is it OK to merge the master into this branch and then, if successful, merge back into master?

Yes, merging master should be fine.