HelmReleases sometimes pick the wrong API group

[kingdonb]

Expected behaviour

I have a cluster where I have both Loft (https://loft.sh) and Flux installed. Both create APIs in the Kubernetes resources called "HelmReleases" and wherever we're calling into the cluster for HelmReleases unqualified, it has the potential to cause issues.

When the user is in the GitOps Tools UI, any HelmReleases should visually appear as "HelmReleases" but on the backend they should always be requested with their fully qualified name, whether in an informer, in a plain get command, describe or whatever. GitOps Tools UI is only interested in Flux HelmReleases.

Actual behaviour

The Loft HelmReleases API is sometimes used, causing errors. It looks like this, or alternatively it could sometimes pull up the resource so you can see the HelmRelease content, but it's the wrong HelmRelease:

Steps to reproduce

This surfaced in the prerelease (edge) branch. The symptom is when you look at the HelmReleases on the cluster, they all appear with an error state because they weren't able to be parsed and consumed. The open resource behavior shows the selected resource is a helmreleases.clusters.loft.sh and even if the user is not familiar with this API, it can get in the way:

$ k get helmreleases.cluster.loft.sh -A
NAMESPACE                         NAME                     CHART                   VERSION       REVISION   CREATED AT
vcluster-hephy-stg-turkey-local   hephy-stg                vcluster                0.11.1        1          2023-05-15T02:26:32Z
vcluster-howard-moomboo-space     howard-moomboo-cluster   vcluster                0.11.1        4          2023-08-22T16:51:39Z
ingress-nginx                     ingress-internal         ingress-nginx           4.7.1         14         2023-06-30T21:39:44Z
ingress-nginx                     ingress-nginx            ingress-nginx           4.7.1         11         2023-06-30T21:39:44Z
ingress-nginx                     ingress-public           ingress-nginx           4.7.1         15         2023-06-30T21:39:44Z
ingress-nginx                     ingress-public           ingress-nginx           4.4.3         6          2023-02-01T20:42:47Z
monitoring                        kube-prometheus-stack    kube-prometheus-stack   48.6.0        12         2023-08-27T15:22:00Z
kubedb-system                     kubedb                   kubedb                  v2022.10.18   7          2022-11-08T14:41:13Z
kube-system                       kured                    kured                   5.2.0         15         2023-09-05T15:13:11Z
kwasm                             kwasm-operator           kwasm-operator          0.2.0         1          2023-01-10T01:44:47Z
loft                              loft                     loft                    3.2.4         1          2023-09-05T15:17:16Z
loft                              loft-agent               loft-agent              3.2.4         1          2023-09-05T15:17:36Z
monitoring                        loki-stack               loki-stack              2.9.11        10         2023-08-01T19:11:00Z
vcluster-moo-cluster-mgorr        moo-cluster              vcluster                0.11.1        2          2023-08-22T16:51:48Z

All of these HelmReleases were auto-generated. When I run kubectl get helmreleases I am at risk of pulling these, instead of the Flux helmreleases. This hasn't been noticed as an issue until the recent changes to use the server-side API, when it looks like the chances increased that users will trip over this.

Versions

kubectl version: Flux version: Git version: Azure version: Extension version: v0.25.1693332368 (Prerelease) VSCode version: Operating System (OS) and its version:

[kingdonb]

This has been resolved in v0.25.1 and it got a mention in the CHANGELOG:

• Now works with Loft.sh (resolving HelmRelease APIService name conflict)

We solved the issue by making a record of Flux types (Kinds) and fully qualifying the Flux toolkit kinds whenever they are used in a context where they have potential to get confused.