Add kubeconfig export and cluster listing commands

[maximiliantech]

After ocpctl env apply, only the platform cluster ends up in the kubeconfig. The onboarding cluster and any provisioned ControlPlane clusters are not accessible via kubectl without manual steps.

Two commands would fix this:

ocpctl env list clusters [<env>]
Interactive selector listing all clusters for an environment (platform, onboarding, and ControlPlane clusters from the operator's Cluster CRs). Selecting one triggers the kubeconfig export.

ocpctl env export kubeconfig -n <cluster-name>
Merges the kubeconfig for a specific cluster into ~/.kube/config. Also usable standalone for scripting.

[AndresNico]

Was just reading through that and think those are great feature to add 👍
A few ideas that came to my mind as I was reading through it:

ocpctl env list clusters []
Interactive selector listing all clusters for an environment (platform, onboarding, and ControlPlane clusters from the operator's Cluster CRs). Selecting one triggers the kubeconfig export.

I am not sure about the command structure here. When I type in that command I would expect ocpctl to list all clusters belonging to an env (which might also be a good thing to add) not modify my kubeconfig. Maybe we could merge that into the export command and if the user does not provide a cluster name we open an interactive selector

ocpctl env export kubeconfig -n
Merges the kubeconfig for a specific cluster into ~/.kube/config. Also usable standalone for scripting.

• Maybe we can also add a get command which writes to stdout (like kind with get kubeconfig and export kubeconfig)
• I think we should not automatically write to ~/.kube/config but include a flag for a target file and also evaluate $KUBECONFIG
• I am not sure about putting that under environment as it is imo not targeted towards a specific env but just a specific cluster, maybe we should add kubeconfig as its own high level subcommand so ocpctl kubeconfig export

Idea:

Maybe it makes sense to not use the cluster name but the cluster type, so for example ocpctl env export kubeconfig <env> -t onboarding and then you get the kubeconfig for the onboarding cluster. With that it would make sense to put it under the env subcommand and users do not have to deal with individual names. That would of course get messy if we have more than 1 cluster per type

Looking forward to hear your opinion on that

[maximiliantech]

While discussing this issue with @AndresNico, we noticed that the ocpctl command line structure differs from other well-known K8s CLI tools like kubectl, kind or kubebuilder.
Right now, we use a <resource> <verb> approach e.g. ocpctl env list. Instead we should switch to an <verb> <resource> approach to align with other K8s CLIs. What do you think @ValentinGerlach?

---

Proposal for ocpctl command line enhancements

@AndresNico and I have discussed how the developer flow could look like. What do you think about the following proposal @ValentinGerlach?

Get output of all environments

> ocpctl list env
first
second

This command is already there but just switched from <resource> <verb> approach to <verb> <resource> (feels more natural).

Get output of all clusters across all environments

> ocpctl list clusters
first
  |--platform-cluster
  |--onboarding-cluster
  |--mcp-fs23kls-...
  |--mcp-63ldgs-...

second
  |--platform-cluster
  |--onboarding-cluster
  |--mcp-p7qenk-...

Export specific cluster kubeconfig from an environment to ~/.kube/config like kind export kubeconfig -n <kind-cluster-name>

> ocpctl export kubeconfig -e <env-name> -n <cluster-name>

Get specific cluster from an environment to stdout

> ocpctl get kubeconfig -e <env-name> -n <cluster-name>