Remove/migrate UI calls to Kubeops

[antgamdia]

Summary

As part of the analysis performed for #4764, I noticed we still have several calls to the kubeops endpoints that should be properly migrated to the Resources plugin or the PackageRepositories plugin.

Background and rationale

Once we get rid of the Kubeops calls for managing repositories, there is no reason for us to maintain Kubeops. Therefore, any remaining call should be migrated.

Description

First, further analysis of what we have to delete or migrate has to be carried out.

Acceptance criteria

• We have identified which are the calls to the Kubeops service.
  • Done at Mark old kubeops calls to be migrated to the resources API #5023
• The current calls to Kubeops have been properly migrated to the corresponding services.
• Kubeapps continues to work after scaling Kubeops's deployment down to 0 replicas.

Additional context

Note that, first, we have to finish the implementation of the Helm-plugin Repositories API.

[absoludity]

Kubeops currently has the kubeops-ns-discovery ClusterRole which gives access to list the namespaces of a cluster (before they are filtered by user RBAC). We'll need to move this cluster role and apply it to the kubeapps-apis service account so that we can use it from the resources plugin for similar functionality.

[antgamdia]

For now, I have indentified:

• https://github.com/vmware-tanzu/kubeapps/blob/main/dashboard/src/shared/Kube.ts
  • getResource
  • getAPIGroups (Update from Rafa: does not apply, it is a direct call to K8s API)
  • getResourceKinds (Update from Rafa: does not apply, it is a direct call to K8s API)
  • canI (Update from Rafa: done in Remove all pending endpoints from Kubeops #5249)
• https://github.com/vmware-tanzu/kubeapps/blob/main/dashboard/src/shared/Namespace.ts
  • list (Update from Rafa: done in Migrate namespaces retrieval from Kubeops to Kubeapps APIs #5239)
• https://github.com/vmware-tanzu/kubeapps/blob/main/dashboard/src/shared/Operators.ts
  • All of them, but it should be carried out at Pluggable support for Operators in Kubeapps #4920

[castelblanque]

For now, I have indentified

After some investigation:

• getResource is not used and thus has been removed (pending PR)
• getAPIGroups/getResourceKinds are direct K8s APIs calls unrelated to Kubeops. They are only used when operators are enabled.
• canI will be moved into resources plugin (pending PR)

The only remaining endpoint in Kubeops will be a simple “give me this operator logo” (this line). Kubeops only makes a subsequent K8s API call, so no added value. Given that the call is related to operators, it will be moved to be done directly from the frontend (k8s api calls are allowed when using operators).