[enh] Associate errors with respective releases in ClusterSummary

[wahabmk]

Currently The status of individual helm releases are in .status.helmReleaseSummaries in ClusterSummary, whereas if any of the releases fails, the error message is reported in .status.featureSummaries without any means of knowing which release this error is associated with. For example here, the error in failureMessage is for the nginx chart, however there seems to be no reliable way to associate it with the ngnix release other than parsing the failureMessage string which seems hacky:

. . .
status:
  dependencies: no dependencies
  featureSummaries:
  - failureMessage: |
      chart: ingress-nginx, release: nginx, context deadline exceeded
    featureID: Helm
    hash: uA6cXbZNMVUuwWB5pElrUXztH9f0MAd2jpJ6KBidJBg=
    lastAppliedTime: "2026-03-23T09:53:48Z"
    status: Provisioning
  helmReleaseSummaries:
  - releaseName: nginx
    releaseNamespace: nginx
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=
  - releaseName: postgres-operator
    releaseNamespace: postgres-operator
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=
. . .

So the suggestion is to have a mechanism via which we may be able to associate errors with relevant releases.

[gianlucam76]

something like this:

  status:
    dependencies: no dependencies
    featureSummaries:
    - consecutiveFailures: 12
      failureMessage: 'release name check failed: cannot reuse a name that is still
        in use'
      featureID: Helm
      hash: wFhMn1Ap3BaXYgWatgZCIwurH58IgDRbfgr3wd9TO7s=
      lastAppliedTime: "2026-03-24T10:01:05Z"
      status: Failed
    helmReleaseSummaries:
    - failureMessage: 'release name check failed: cannot reuse a name that is still
        in use'
      releaseName: kyverno-latest
      releaseNamespace: kyverno
      status: Managing
      valuesHash: jLsMQyyUoho8Lt2VvihRy3KiiKWLWuSkupgNiEdY1DI=
    nextReconcileTime: "2026-03-24T10:01:35Z"

[wahabmk]

@gianlucam76 This looks good. Apologies for the late response but I was thinking through some more scenarios.

Scenario 1

nginx:     Deployed -> Failed -> Provisioning
postgres:  Deployed

With the new changes, we will have an error message in helmReleaseSummaries[0].failureMessage for nginx so we can know that it failed. However, we still won't have any means to know that featureSummaries[0].status=Provisioning is for nginx only especially because the valuesHash is set for both nginx and postgres.

status:
  dependencies: no dependencies
  featureSummaries:
  - failureMessage: |
      chart: ingress-nginx, release: nginx, context deadline exceeded
    featureID: Helm
    hash: uA6cXbZNMVUuwWB5pElrUXztH9f0MAd2jpJ6KBidJBg=
    lastAppliedTime: "2026-03-25T12:37:35Z"
    status: Provisioning
  helmReleaseSummaries:
  - releaseName: nginx
    releaseNamespace: nginx
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=
  - releaseName: postgres-operator
    releaseNamespace: postgres-operator
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=

Scenario 2

nignx:     Deployed -> Failed -> Provisioning
postgres:  Deployed -> Failed -> Provisioning

In this case both have failed previously and are now Provisioning, but again we wont be able to tell programatically if:

• nginx is the one Provisioning
• or postgres is the one Provisioning
• or both are Provisioning

status:
  dependencies: no dependencies
  featureSummaries:
  - failureMessage: |
      chart: ingress-nginx, release: nginx, context deadline exceeded
      chart: postgres-operator, release: postgres-operator, context deadline exceeded
    featureID: Helm
    hash: +OIMqZZ3LuRy6P8yCT45zb92Y6i4BAj1W94pMGq9wfk=
    lastAppliedTime: "2026-03-25T13:45:16Z"
    status: Provisioning
  helmReleaseSummaries:
  - releaseName: nginx
    releaseNamespace: nginx
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=
  - releaseName: postgres-operator
    releaseNamespace: postgres-operator
    status: Managing
    valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=

[gianlucam76]

Thank you @wahabmk
The behavior you are suggesting can't be supported due to how Sveltos manages state and triggers.

Sveltos does not track individual Helm charts for redeployment triggers. Instead, it monitors a hash of the entire HelmCharts section. If any part of that section changes, a reconciliation is triggered for the entire group.

Once an update is triggered, Sveltos iterates through the listed Helm charts sequentially. For each chart, it performs a two-step validation to decide whether to skip an upgrade:

• Values Check: Has the values hash changed?
• Version Check: Does the version currently on the managed cluster match the version specified in the Profile?

Sveltos only skips a specific chart if both the version and the values are already in sync.

Also by default, Sveltos follows a "fail-fast" approach. If you have 3 Helm charts and the second one fails to deploy, Sveltos will stop immediately and will not attempt to deploy the third chart. To override this behavior and force the controller to process the entire list regardless of individual failures, you must explicitly set continueOnError: true.

If you are interested in seeing resources currently deployed by Sveltos (including helm charts with version) you can check the ClusterConfiguration (there is one instance per cluster).