Discrepancy between name of host cluster in Argo and Backstage

[djeremiah]

Migrated from https://github.com/crossplane-contrib/back-stack/issues/41

In backstage/catalog/resources/hostcluster.yaml, the Host cluster is named hostcluster. However, when it's registered with Argo, it is named in-cluster. This leads to a discrepancy when creating an application to run on the cluster (i.e. without creating "spoke" clusters), since line 65 of backstage/catalog/templates/application/template.yaml extracts the name of the Catalog-resource cluster as the cluster_id - resulting in an Argo Application trying to deploy to hostcluster when Argo only knows about a cluster named in-cluster.

I'm not sure how to resolve this. I was able to make a successful application deployment by manually changing Argo's view of the name of the cluster to hostcluster, to match the name in the Backstage catalog, but I'd rather find a way to do so from GitOps configuration rather than manual action. Some ideas:

when I tried changing the name in hostcluster.yaml to in-cluster (so that it would match what Argo calls the "self" cluster), Backstage became inaccessible - I got 502 Bad Gateway when accessing https://backstage-7f000001.nip.io/, despite the pods, service, ingress etc. all looking healthy. presumably if there was a way to override Argo's cluster-naming via GitOps configuration, that would work - but I don't see any such configuration in the source repo alternatively, the backstage/catalog/templates/application/template.yaml file could be updated with some (pseudo-code) if (.name == 'hostcluster') then {'in-cluster'} else {.name} - but, as my pseudo-code probably makes clear, I have no idea how to accomplish that.

[djeremiah]

Generally, the control plane should not be self-hosting workloads. It might make more sense to remove the host cluster as a target from the application template. Alternatively, we could have multiple catalog entries. One for backstage to reference its host cluster, and one for that cluster as a workload target. There's nothing to prevent these being the same thing.

[scubbo]

Generally, the control plane should not be self-hosting workloads

While this is certainly reasonable in-production, I'd strongly suggest reconsidering that as a constraint for this proof-of-concept demo. I just want to show my coworkers (from my laptop) how the BACK stack can be used to create and deploy applications - I don't want to incur cloud expenses creating a "real" cluster on AWS/GCP to do so!

[djeremiah]

I've updated the hub composition to rename the in-cluster config in argo to hostcluster. This should allow workloads to target the hostcluster without manual intervention. Please reopen if it doesn't work for you.

[scubbo]

Awesome, thanks a ton!