Show Helm charts from all Helm repos in the Helm chart explorer

[datho7561]

The only Helm repo that is available in the Helm Chart explorer is the OpenShift Helm repo, even if the user has configured additional ones outside of VS Code OpenShift. This is a problem, since many of the charts in the OpenShift Helm repo (including most of the interesting ones like Postgres, Redis, and Jenkins) only work on OpenShift, since they rely on Routes or DeploymentConfigs.

In order to get the extension to work better with other Kubernetes clusters, I think that we should:

• Show all the charts from all the Helm repos that the user has configured in the Helm chart explorer webview
• Add some sort of indicator, perhaps a small chip, to show which charts come from which repo
• Add a list of checkboxes in the Helm chart explorer to show/hide charts for a particular repo

There is a mechanism to add/remove Helm repositories in the Kubernetes extension, so I don't think we need to do that as part of this issue.

[datho7561]

I think @msivasubramaniaan mentioned he was working on this

[msivasubramaniaan]

@datho7561 I haven't started yet. I'll pick it for this sprint

[msivasubramaniaan]

Hello @mohitsuman and @datho7561

When we plan to integrate the CLI approach for getting all the installed Helm repos, helm search repo -l -o=json there were some discrepancies between the web API call and the CLI on helm.

• Web API call(https://charts.openshift.io/index.yaml) - wavefront

- annotations:
      charts.openshift.io/digest: sha256:27d8a54382f1c39c55f9239bc7e17195d4c416742113fcaae1013b93b1689be0
      charts.openshift.io/lastCertifiedTimestamp: '2023-04-14T19:48:53.916688+00:00'
      charts.openshift.io/provider: VMWare
      charts.openshift.io/providerType: partner
      charts.openshift.io/submissionTimestamp: '2023-04-14T19:55:53.925857+00:00'
      charts.openshift.io/supportedOpenShiftVersions: '>=4.6'
      charts.openshift.io/testedOpenShiftVersion: '4.9'
    apiVersion: v2
    appVersion: 1.16.0
    dependencies:
    - condition: kubeStateMetrics.enabled
      name: kube-state-metrics
      repository: https://prometheus-community.github.io/helm-charts
      version: ^4.16.0
    description: Wavefront Collector for Kubernetes
    digest: 16892309c6c0be3f669be955f0ca162e432de28af631ad8e781912dd6f7cead3
    home: https://www.wavefront.com
    keywords:
    - metric
    - monitoring
    - observability
    - alerting
    kubeVersion: '>= 1.19'
    maintainers:
    - email: [email protected]
      name: akodali18
    - email: [email protected]
      name: ginwoopak
    - email: [email protected]
      name: iplay88keys
    - email: [email protected]
      name: jerrybelmonte
    - email: [email protected]
      name: johncornish
    - email: [email protected]
      name: josephgee
    - email: [email protected]
      name: jyuqi
    - email: [email protected]
      name: m25n
    - email: [email protected]
      name: mmichael
    - email: [email protected]
      name: priyaselvaganesan
    name: wavefront
    sources:
    - https://github.com/wavefrontHQ/wavefront-collector-for-kubernetes
    - https://github.com/wavefrontHQ/wavefront-proxy
    urls:
    - https://github.com/openshift-helm-charts/charts/releases/download/wavefronthq-wavefront-1.13.1/wavefront-1.13.1.tgz
    version: 1.13.1 

• CLI response - wavefront

annotations:
  charts.openshift.io/name: wavefront
apiVersion: v2
appVersion: 1.16.0
dependencies:
- condition: kubeStateMetrics.enabled
  name: kube-state-metrics
  repository: https://prometheus-community.github.io/helm-charts
  version: ^4.16.0
description: Wavefront Collector for Kubernetes
home: https://www.wavefront.com
keywords:
- metric
- monitoring
- observability
- alerting
kubeVersion: '>= 1.19'
maintainers:
- email: [email protected]
  name: akodali18
- email: [email protected]
  name: ginwoopak
- email: [email protected]
  name: iplay88keys
- email: [email protected]
  name: jerrybelmonte
- email: [email protected]
  name: johncornish
- email: [email protected]
  name: josephgee
- email: [email protected]
  name: jyuqi
- email: [email protected]
  name: m25n
- email: [email protected]
  name: mmichael
- email: [email protected]
  name: priyaselvaganesan
name: wavefront
sources:
- https://github.com/wavefrontHQ/wavefront-collector-for-kubernetes
- https://github.com/wavefrontHQ/wavefront-proxy
version: 1.13.1

provider, providerType, icon and many more keys were missing. How shall we proceed especially on filter based workflow.

Are you guys okay with adding static icons and removing the Provider and Provider Type filtering and moving forward the filtering will be only on repository level.

[vrubezhny]

IMHO, it's OK to have a static icons. On filtering - does it make sense if we provide filtering by keywords instead by provider and providerType?

keywords:
    - metric
    - monitoring
    - observability
    - alerting

[msivasubramaniaan]

IMHO, it's OK to have a static icons. On filtering - does it make sense if we provide filtering by keywords instead by provider and providerType?

keywords:
    - metric
    - monitoring
    - observability
    - alerting

Thanks @vrubezhny for your input. As my understanding the keyword based filtering not having much values.

[datho7561]

I also think that filtering by repo and keywords is a good idea, and think that the static icons are okay.

Somewhat unrelated: Are we using the keywords for the search currently? If not, it might be worthwhile adding something like this. See the Devfile search filtering by tags; I think we could do something similar here in the Helm Chart search code.

[msivasubramaniaan]

I also think that filtering by repo and keywords is a good idea, and think that the static icons are okay.

Somewhat unrelated: Are we using the keywords for the search currently? If not, it might be worthwhile adding something like this. See the Devfile search filtering by tags; I think we could do something similar here in the Helm Chart search code.

Even keywords were missing on some charts:

helm show chart openshift/castai-castai-agent
annotations:
  charts.openshift.io/name: castai-agent
apiVersion: v2
appVersion: v0.42.2
description: CAST AI agent deployment chart.
kubeVersion: '>= 1.19'
name: castai-agent
type: application
version: 0.52.0

Also there were no keywords based filtering on dev console as well. Do the keyword based search really value for the workflow?

[vrubezhny]

Even keywords were missing on some charts:

That's ok. In Devfile Registry Search view we show all devfiles in case no a tag is selected in the filter. Once any tags get selected we show the only the Devfiles that have any of the selected tags. So it's still possible to show the Devfiles with no tags set in the search results