Handle cluster metadata for GitOps modules

[seansund]

Currently if the gitops modules need cluster metadata (ingress subdomain, cluster type, etc), they include a direct dependency on the cluster module OR hard code the values, particularly for cluster type. The gitops modules that install operators also include a dependency on the OLM module to get the namespace locations then make some major assumptions about the operator configuration (mostly assuming we are installing on OpenShift).

As we move to support vanilla kubernetes clusters, we need to have more metadata available and do it in a way that is appropriate for GitOps (i.e. not have direct dependency on the cluster). The way we are proposing to handle this is by storing the metadata in the GitOps repo. There are two main categories of metadata to include:

Cluster info

• Ingress subdomain(s) - since there may be multiple, there should at least be a default to start, other named subdomains can be added
• Cluster type: kubernetes or openshift
• Kubernetes version
• OpenShift version (if applicable)

Operator info

• Package manifests (lists operator names, catalog source, catalog namespace, and channel(s))
• Operator namespace (namespace where cluster-wide operators are installed)

This information will be stored in yaml files in the gitops repo. Since the gitops repo supports multiple tenants, the files will be stored in directories based on the cluster name.

To access this information we we will provide a data source in the Gitops terraform provider to retrieve the necessary information from the gitops repo.