shouldUpgrade/deployHelmChart (push mode) scope the redeploy decision per chart: a chart is only re-installed/upgraded if its own spec hash changed or drift-detection flagged it (NeedsRedeploy), per #1915.
Pull mode's equivalent, prepareChartForAgent, has no such gate:
// In pull mode always treat it as an install. This will allow us to get list of resources helm would install (equivalent
// of helm template). Those resources will be made available for the agent inside ConfigurationBundles.
helmRelease, _, err := handleInstall(ctx, dCtx, instantiatedChart, "",
registryOptions, true, true, logger)Every chart in the ClusterSummary is re-templated and re-bundled for sveltos-applier on every Helm-feature reconcile, regardless of whether that specific chart changed. Reproduced via test/fv/drift_test.go's [PULLMODE1] "React to configuration drift and verifies Values/ValuesFrom" test: changing one chart's values causes an unrelated chart with driftDetectionIgnore set to be reverted to its ClusterProfile-defined baseline.
The fix should reuse the same signals #1915 introduced (NeedsRedeploy, spec-hash diff against last-recorded hash) inside prepareChartForAgent, skipping re-render for charts that neither changed nor drifted. This doesn't require managed-cluster visibility — those signals are already tracked on ClusterSummary.Status in the management cluster, and sveltos-applier already reports confirmed success/failure per deploy via ConfigurationGroup, so "last successfully applied hash" bookkeeping would be reliable.
shouldUpgrade/deployHelmChart(push mode) scope the redeploy decision per chart: a chart is only re-installed/upgraded if its own spec hash changed or drift-detection flagged it (NeedsRedeploy), per #1915.Pull mode's equivalent,
prepareChartForAgent, has no such gate:Every chart in the ClusterSummary is re-templated and re-bundled for sveltos-applier on every Helm-feature reconcile, regardless of whether that specific chart changed. Reproduced via
test/fv/drift_test.go's[PULLMODE1]"React to configuration drift and verifies Values/ValuesFrom" test: changing one chart's values causes an unrelated chart withdriftDetectionIgnoreset to be reverted to its ClusterProfile-defined baseline.The fix should reuse the same signals #1915 introduced (
NeedsRedeploy, spec-hash diff against last-recorded hash) insideprepareChartForAgent, skipping re-render for charts that neither changed nor drifted. This doesn't require managed-cluster visibility — those signals are already tracked onClusterSummary.Statusin the management cluster, and sveltos-applier already reports confirmed success/failure per deploy viaConfigurationGroup, so "last successfully applied hash" bookkeeping would be reliable.