Given: https://registry.terraform.io/providers/hashicorp/google/5.3...

how would any reasonable person know what https://registry.terraform.io/providers/hashicorp/google/5.3... to enable without (a) trying it and squinting at the error message (b) clicking on the API documentation <https://cloud.google.com/run/docs/reference/rest/v2/projects...> then realizing it, also, does not mention run.googleapis.com, click on "supported service endpoints" <https://cloud.google.com/run/docs/reference/rest#rest_endpoi...> and only then learning about https://cloud.google.com/run/docs/reference/rest#service:-ru...

Repeat for https://registry.terraform.io/providers/hashicorp/google/5.3... although in both cases I guess the astute reader may have spotted the run.googleapis.com in the forbidden service labels and cloudidentity.googleapis.com in the example

Since, to the best of my knowledge those bindings are auto generated <https://github.com/GoogleCloudPlatform/magic-modules#magic-m...>, I would hypothesize it is not insurmountable drop in the seemingly existing declaration of APIs required: https://github.com/GoogleCloudPlatform/magic-modules/blob/7d... https://github.com/GoogleCloudPlatform/magic-modules/blob/7d...

I am about to go through this so happy to give feedback

Can you please update the terraform docs for google batch? In [1] it’s really difficult to know what everything in the json configuration is under the base64encode() call. What levers can I pull? How do I run something more complex than hello world? Do I need my CICD to upload scripts to GCS and have the instance download them at runtime and hardcode that path into the batch script?

[1] https://cloud.google.com/batch/docs/create-run-job-using-ter...

It seems as though Google Batch does not have a native Terraform resource. The document in [1] seems like a workaround that leverages the Cloud Scheduler Terraform resource, but submit a job using the JSON configuration. The various fields that can be used in the JSON are within [2]. Regarding using GCS there is an example in [3]. I found more samples in [4]

[2] https://cloud.google.com/batch/docs/reference/rest/v1/projec... [3] https://cloud.google.com/batch/docs/create-run-job-storage#u... [4] https://github.com/GoogleCloudPlatform/batch-samples/tree/ma...

This is probably more a request at the compute team/gke teams but...spot management.

For example, managing a spot fleet in AWS via terraform is filled with features and levers I can pull. It's easy to manage basic scale-out/scale-in procedures and allows me to set thresholds.

In GCP, as I understand it, I can only manage a node pool at a basic level.

EDIT: Also, yell at the people who manage the python library.

https://cloud.google.com/python/docs/reference/container/lat...

Generated samples suck - take a look at the boto3 docs and see if they tell you to go look at code generated samples.

Rinse and repeat - someone complains about cloud provider, a cloud provider person shows up and makes a "we want to hear more about your problems" statement, people reply, they do nothing. How many times has this happened? I'm more disgusted by the farce than by the lack of action.

Don't you have feedback buttons on the docs? What happens to the feedback from those? Please prove you consider feedback before asking people for more of it.

A few months ago I was working on migrating cloud build for a personal project and hit a documentation error. Submitted a correction via the feedback button and it got fixed few days later. To be honest I was a little surprised by how fast it got fixed.

A general issue I have with GCP docs is that they are overly implicit. Often the interaction of two features is implied but not specified. Another issue I have is when implementation details are waved away rather than explained. It adds up to an experience where I am trying to read between the lines of the GCP docs for a feature to understand what is really happening.

AWS docs are the opposite. They are often very long and verbose, but once you read the whole manual, you can be guaranteed to have a good understanding of the service.

My advice for the Google team would be that if you are ever writing documentation and ask yourself “does the customer really need to know about this?”, the answer should always be yes.