CrashLoopBackOff of pods - GCP deployment

[MatteoFelici]

Expected Behavior

When installing feast with helm on a GKE cluster, following the doc, I expect all pods to be up and running when kubectl get pods.

Current Behavior

I get both feast-feast-core-869f6d6bcb-6fh7j and feast-feast-online-serving-7f99959884-zhqg7 in "CrashLoopBackOff" status after 7 restarts.

After kubectl describe pods I get a type: Warning / Reason: FailedMount / From: kubelet, gke-feast-default-pool-ac080818-0m18 / Message: MountVolume.SetUp failed for volume "feast-feast-core-config" : couldn't propagate object cache: timed out waiting for the condition for the first pod.

Steps to reproduce

Follow steps from 0 to 4 on the doc for GCP deployment.

Specifications

• Version: latest
• Platform: Mac OS

[woop]

I think this might be related to #806

Will try to run through the guide today to debug it.

[Xia-Minghong]

I solved this issue by overriding the default gcp credential values in the yaml config. The default key file names for "feast-gcp-service-account" for both feast-core and feast-batch-serving is "credentials.json". If your secret uses a different file name (e.g. key.json), make sure to override the config by doing the following:

feast-core:
  gcpServiceAccount:
    enabled: true
    existingSecret:
      name: feast-gcp-service-account
      key: key.json
...
feast-batch-serving:
  enabled: true
  gcpServiceAccount:
    enabled: true 
    name: feast-gcp-service-account
    key: key.json

[woop]

I just ran into this problem as well. I have updated all the documentation and ensured that the guide works end to end. Please have a look at the guide here @MatteoFelici. https://docs.feast.dev/getting-started/deploying-feast/kubernetes

Closing the issue for now, please let me know if it isn't resolved.