Challenges with OCI URLs and Helm repositories: No automatic chart updates?

[carrodher]

Hi all,

We’re currently testing Flux’s usability with an index.yaml based on OCI URLs. Flux supports both traditional Helm repositories and OCI-based Helm repositories, as documented here:

• Flux & Helm HTTPS repos docs.
• Flux & Helm OCI repos docs.

However, when using OCI repositories, there is no defined interval for the Flux Source Controller to check for updates in the Helm repo, meaning there’s no automatic reconciliation process. This differs from traditional Helm repos, which benefit from regular updates due to the presence of an index.

A HelmRelease in Flux defines an "interval" (see HelmRelease docs) which defines the interval at which the HelmRelease is reconciled. This reconciliation process includes upgrading a chart release if there's a new chart version published in the Helm repository. However, when working with OCI Helm repositories, Flux cannot inherently detect new chart versions.

This is the reason why a Helm repository index (regardless it uses OCI-based URLs or not) is key for automating upgrading to new chart versions with Flux.

Testing Helm OCI-based URLs on Helm repo index

• I served through NGINX a very simple Helm repo index listing MariaDB:

apiVersion: v1
entries:
  mariadb:
    - annotations:
      (...)
      appVersion: 11.4.3
      (...)
      name: mariadb
      (...)
      urls:
        - https://foo/bar/mariadb-19.0.6.tgz
      version: 19.0.6
generated: "2024-10-01T10:06:21.106464648Z"

• Next, we created a HelmRepo and HelmRelease in Flux:

$ kubectl get helmrepo
NAME        URL                                           AGE   READY   STATUS
podinfo     https://a00a-192-157-215-178.ngrok-free.app   2m    True    stored artifact: revision 'sha256:6fec7c7720d112184700a0d1280bae658bb44f17bf91a5c2318113e8780a1fe8'
$ kubectl get helmrelease
NAME        AGE     READY   STATUS
mariadb     4m29s   True    Helm install succeeded for release default/mariadb.v1 with chart [email protected]

• We then transformed the index.yaml to use OCI URLs:

-         - https://foo/bar/mariadb-19.0.6.tgz
+         - oci://foo/bar/mariadb:19.0.6

• And we added a new chart version:

apiVersion: v1
entries:
  mariadb:
    - annotations:
      (...)
      appVersion: 11.4.3
      (...)
      name: mariadb
      (...)
      urls:
        - oci://foo/bar/mariadb:19.0.7
      version: 19.0.7
    - annotations:
      (...)
      appVersion: 11.4.3
      (...)
      name: mariadb
      (...)
      urls:
        - oci://foo/bar/mariadb:19.0.6
      version: 19.0.6
generated: "2024-10-01T10:06:21.106464648Z"

• However, despite waiting for reconciliation, the new version failed to download:

$ kg helmchart
NAME                CHART     VERSION   SOURCE KIND      SOURCE NAME   AGE   READY   STATUS
default-mariadb     mariadb   19.x      HelmRepository   podinfo       22m   False   chart pull error: failed to download chart for remote reference: Get "oci://foo/bar/mariadb:19.0.7": unsupported protocol scheme "oci"

It seems that Flux expects "classic" Helm repositories to use HTTP(S) URLs and doesn’t yet support OCI URLs for Helm repositories.

[stefanprodan]

This is how you should define the Helm OCI:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 10m
  url: oci://ghcr.io/stefanprodan/charts/podinfo
  ref:
    semver: ">6.0.0"
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 10m
  releaseName: podinfo
  chartRef:
    kind: OCIRepository
    name: podinfo

[juan131]

Hi @stefanprodan

There won't be any new chart versions' automatic discovery using an OCIRepository as stated by @carrodher, which is the main goal here. Am I right?

By the way, OCI references on index.yaml files for Helm is sth that works. I personally reported the issue some time ago and I can confirm it's addressed, see:

• Helm index.yaml with OCI references  helm/helm#12322

[stefanprodan]

There won't be any new chart versions' automatic discovery using an OCIRepository

Yes it is, that what semver does. For your chart set it to >19.0.0

[juan131]

Hi @stefanprodan

Thanks! I just did a new test using a OCI repos (hosted on a custom Harbor instance) and uploading a new version. I confirm it works as shown below:

$ kubectl get helmrelease -w
NAME     AGE     READY     STATUS
foo      9m55s   True      Helm install succeeded for release test/foo.v1 with chart [email protected]+0a43d022056a
foo      11m     True      Helm install succeeded for release test/foo.v1 with chart [email protected]+0a43d022056a
foo      11m     Unknown   Running 'upgrade' action with timeout of 5m0s
foo      11m     Unknown   Running 'upgrade' action with timeout of 5m0s
foo      11m     True      Helm upgrade succeeded for release test/foo.v2 with chart [email protected]+7c7e0f9b7068
foo      11m     True      Helm upgrade succeeded for release test/foo.v2 with chart [email protected]+7c7e0f9b7068
foo      11m     True      Helm upgrade succeeded for release test/foo.v2 with chart [email protected]+7c7e0f9b7068

$ kg ocirepository -w
NAME     URL                                     READY     STATUS                                                                                                                                                         AGE
foo.     oci://harbor.juan.ariza/charts/foo      True      stored artifact for digest '11.2.21@sha256:0a43d022056a52857863569c5bef63f153a7188ad73298b2279cb4987c9bd314'                                                   3m12s
foo.     oci://harbor.juan.ariza/charts/foo      Unknown   building artifact: new revision '11.2.22@sha256:7c7e0f9b7068424afb1a18c84c48d22f3713e3d0b9dd0ae2942296dad284a48b' for 'harbor.juan.ariza/charts/foo:11.2.22'   11m
foo.     oci://harbor.juan.ariza/charts/foo      True      stored artifact for digest '11.2.22@sha256:7c7e0f9b7068424afb1a18c84c48d22f3713e3d0b9dd0ae2942296dad284a48b'                                                   11m
foo.     oci://harbor.juan.ariza/charts/foo      True      stored artifact for digest '11.2.22@sha256:7c7e0f9b7068424afb1a18c84c48d22f3713e3d0b9dd0ae2942296dad284a48b'                                                   11m

This would solve the issue with automatic chart updates.

[juan131]

That said, if a valid Helm index is maintained (for compatibility with helm search command) and it's using OCI URLs, why shouldn't that be supported if Helm actually supports it?