goobysnack

The pods in our deployment can take up to 90s to fully initialize and pass the readiness probe (yay java!). The load balancer healthcheck is just hitting the tomcat listener....

I opened a Google case, and their response is "by design", and offered to open a feature request. That seems more like a bug than a feature. My response: ```...

I learned that the backend-config isn't assigned to the ingress annotation, it's assigned to the workload service. Once you do that, it all works like magic. That was the fine...

I'm blocked by this too. Can we add extra args for the git clone so that it can `--recurse-submodules` TIA.

Are there extra args so that we can configure git in our server config? So we can add `--recurse-submodules` if we need to.

@lkysow I figured this one out too. I added this to my plan workflow: ``` - run: git submodule update --init --recursive && ... ```

> @goobysnack could you share a minimal configuration (no modules or variables) that reproduces this failure? This should be sanitized ``` resource "google_container_cluster" "cluster" { name = clustername project =...

> @goobysnack is there any way to get more minimal & make sure it's runnable? For example, by removing fields that aren't required to reproduce the error. I've tried to...

The issue with "do not set the fleet field" is that then the cluster doesn't fully register correctly. I think you should restore the bug label. JMO.

> @goobysnack could you elaborate on what "doesn't fully register correctly" means? How can you tell whether it's fully registered correctly? Fair question - it's how we discovered this issue....