Based on our discussion today: the easiest way to do this will be not use k8s.io/client-go and github.com/knative/serving/pkg/apis/serving/v1 package at all. With that, we need to have a KUBECONFIG file (or construct it in-memory) which complicates the configuration surface quite a bit.

If all we want to support is GKE, we can:

• imitate gcloud run cli and accept --cluster-location and --cluster options
• use those to get GKE cluster info (endpoint and server CA cert)
• use those to construct an http client (using golang.org/x/oauth2 + /google)
• make API calls to Knative API on the GKE cluster directly
• the tool authenticates to the GKE master endpoint with IAM roles/container.admin role (or equivalent Kubernetes RBAC binding inside the cluster, doesn't really matter).

The only downsides I see are that:

• potential data loss/corruption on ksvc object if knative serving APIs add something (even to fields like metadata:, and run/v1 package is not updated and picked up in this tool).
• dealing with raw JSON and raw endpoints versus using nice client libraries (although, maybe we can actually make run/v1 work with the k8s endpoint by tweaking some options).

Thinking of the configuration from the user perspective:

./cloud_run_release_manager -platform=gke  [-clusters=<MY_CLUSTER1>,<MY_CLUSTER2>] [-cluster-locations=us-central1-a,us-central1-b] [-namespaces=default] [-project=<PROJECT_ID>]

platform is by default managed. We could add support for managing services in CRFM and CRfA at the same time later

For the first implementation of this, we might want to make the optional arguments required. Maybe support a single cluster only

For the first implementation of this, we might want to make the optional arguments required. Maybe support a single cluster only

I think that'll be the case forever, by design. The tool should manage (1) either FM or CRFA, not both simultaneously, (2) only one cluster at a time.