Onboard Koku Cluster

[durandom]

@chargio maintains a long-running cluster in AWS:

https://console-openshift-console.apps.costdemo.openshift.mbulab.xyz/

We would like to

• [ ] adopt the cluster to our ACM instance
• [ ] manage cluster upgrades
• [ ] deploy real or play workloads to the cluster via ArgoCD

Benefits for our community:

• adds additional compute capacity for the Operate First community cloud
• adds a long running AWS cluster

Benefits for Koku / CostManagement:

• real workloads on cluster
• less maintenance

cc @kholdaway

[durandom]

@HumairAK can you comment on what is needed to adopt a cluster? Right now the cluster has oauth for GH configured.

@mimotej please document this process in the hitchhiker guide

[tumido]

bumping this, we have pretty extensive guide for cluster onboarding. @HumairAK can you look into adding the cluster to the fleet?

/kind onboarding /priority important-soon

[HumairAK]

Right now the only known way is to give one of the operate-first admins cluster-admin access to this cluster. (We're still looking in to ways of letting others add their clusters to our acm instance).

We can then add it to acm, and provide acm access to this cluster to anyone else as needed. So from @chargio I will need cluster-admin access to this cluster so I can add it to acm as part of the onboard process.

[chargio]

Please send me the Github handles you want to add as cluster-admin, and I will do it (it will take me a few minutes only)

[sesheta]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[chargio]

Are you still interested in this issue?

[HumairAK]

/remove-lifecycle stale

@chargio we now allow users to create their own managed cluster sets in our acm instance: https://www.operate-first.cloud/apps/content/acm/adding_users_to_acm.html

This way users can onboard their cluster to the operate-cluster fleet. ArgoCD will be auto configured to be able to deploy to this cluster. And you can be onboarded to ArgoCD via: https://www.operate-first.cloud/apps/content/argocd-gitops/onboarding_to_argocd.html

LMK if you have any questions. We can also tie this cluster to our keycloak instance, and delegate auth via keycloak.

If you would also like to manage your cluster via gitops through the operate first org (i.e. store your cluster manifests in this git org, and have argocd depoy them, perform cluster upgrades via prs, etc.), let us know! We don't have exact docs on this yet, but if there's interest we can guide you through it.

[sesheta]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[sesheta]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

[sesheta]

@sesheta: Closing this issue.

In response to [this](https://github.com/operate-first/support/issues/381#issuecomment-1158345734): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.