🚀 New Features
Detect Outdated Helm Chart Versions
Sveltos now periodically checks whether a Helm chart deployed through a ClusterProfile or Profile has a newer version, or a newer same-minor patch, published upstream (HTTP repository or OCI registry). This is detection only: nothing about what gets deployed changes automatically. The result is recorded directly on the ClusterSummary that owns the release, alongside the chart identity already resolved at deploy time, so it's visible per cluster rather than blended across a fleet. latestVersion/latestPatchVersion are only populated when something newer genuinely exists; lastCheckedTime advances on every check regardless of outcome, distinguishing "confirmed up to date" from "not yet checked." A background process (main instance only, to avoid duplicate work across shards) groups deployments that are the same chart from the same source and checks each once; unreachable repositories/registries are skipped and logged rather than blocking the rest, and each check has a timeout. Metrics expose which deployments are behind and the health of the checker itself (last run, failure count). The check interval is configurable and can be disabled.
The dashboard surfaces this in three places: cluster list cards show an icon when a cluster has one or more releases with a newer version or patch available; the addon table on a cluster's detail page gains an "Update Available" column; and a new "Updates" button in the cluster heading queries mcp-server on demand and lists outdated releases with their current and latest available versions.
sveltosctl gets the CLI equivalent: a new show helm-updates command displays, per cluster, every Helm release with a newer version or patch available, filterable by namespace, cluster name, and cluster type. Separately, MCP query failures (as opposed to a successful-but-empty response) now show a distinct "Unable to reach the MCP server" message across all MCP-backed dashboard panels, instead of being indistinguishable from "nothing to report."
PRs: addon-controller #1883, sveltos #772, ui-backend #177, dashboard #180, sveltosctl #442
RemoteURL Support for KustomizationRefs
KustomizationRef.RemoteURL lets a KustomizationRef fetch its content directly from an HTTP/HTTPS endpoint or an OCI registry PolicyRef.RemoteURL. Unlike PolicyRef's OCI path, which flattens all YAML/JSON files across layers into one concatenated blob, this path preserves the fetched content's directory structure, since Kustomize needs it. Namespace/Name/Kind are now optional on KustomizationRef (required only when RemoteURL is unset), and hashing/periodic re-fetch both cover RemoteURL-based refs the same way they already do for PolicyRef.
PR: addon-controller #1882
Instantiate Path/Components Using TemplateResourceRefs
PolicyRef.Path and KustomizationRef.Path/Components can now be Go templates instantiated using TemplateResourceRefs data, not just cluster information. This lets a Kustomize overlay path or PolicyRef directory be selected dynamically based on resources read from the management cluster, instead of being fixed per profile.
PR: addon-controller #1868
Helm Post-Render Strategies
HelmChart.Options gains PostRenderStrategy, controlling whether Helm hooks are included when Patches/PatchesFrom are applied as a post-renderer during install/upgrade: combined (Helm's own default, hooks and templates sent together), separate (hooks and templates sent to the post-renderer in independent invocations, avoiding duplicate-resource errors from post-renderers that de-duplicate by resource identity), or nohooks (only regular templates are post-rendered, matching Helm 3's behavior). Only relevant when Patches or PatchesFrom is set.
PR: addon-controller #1866
EventTrigger Errors Surfaced in EventReport Status
When event-manager processes an EventReport and fails to instantiate the resulting ClusterProfile(s), the error used to be visible only in event-manager's own logs. It's now recorded directly on EventReport.Status, so the failure is visible on the object itself instead of requiring log access.
PR: event-manager #502
mcp-server: Event/Classifier Failure Reporting and Fleet-Wide Label Visibility
Event pipeline tracing now surfaces the error event-manager records when it fails to instantiate a ClusterProfile from an EventReport, so tracing an event-driven deployment tells you directly why no profile was created. Classifier pipeline tracing now also covers ManagementClusterClassifier: tracing by name checks both kinds automatically, reporting cluster match, reconcile failures (bad Lua, resource collection errors), and label ownership/conflicts for either. A new fleet-wide tool lists every label currently being managed by any Classifier or ManagementClusterClassifier across all (or a filtered subset of) managed clusters, along with label ownership and conflicts, mirroring sveltosctl show classifier-labels. Two diagnostic bugs were also fixed: installation health checks reporting agent verification failures as a blank reason, and blocked-dependency names being concatenated with no separator in deployment-error/dependency-analysis output.
The Sveltos MCP Server now exposes 22 tools in total.
PR: mcp-server #63
Dashboard: Classifier View
The dashboard now displays Classifier and ManagementClusterClassifier instances, each showing the number of labels it would set and the number of matching clusters. Selecting an instance lists all matching clusters, inline with the existing Events tab. An "Analyze Pipeline" action calls a new MCP tool that verifies a classifier/cluster pair end to end. The overview section also gains Classifier/ManagementClusterClassifier counts.
PRs: ui-backend #176, dashboard #179
Metrics Across the Fleet
addon-controller, event-manager, and sveltoscluster-manager gain a consistent metrics model, replacing ad hoc or cardinality-unsafe gauges/histograms with properly labeled ones (cluster_type, cluster_namespace, cluster_name, and a *_name label per component's own resource): reconcile duration, reconcile outcome (success/failure with the owning profile/trigger), and last-success timestamp, plus component-specific additions: matching_clusters (addon-controller, event-manager), matching_resources (event-manager), connection_failures and agent_last_heartbeat_timestamp_seconds (sveltoscluster-manager). sveltoscluster-manager also fixes two correctness bugs: a stale Kubernetes-version label combination was never removed after a cluster upgraded, and no metric was ever cleaned up when a cluster was deregistered. All components now correctly prefix metrics with projectsveltos_ and ship the auth-proxy RBAC needed to actually scrape /metrics. A Grafana dashboard is available covering the new metrics.
PRs: sveltoscluster-manager #372, event-manager #503, addon-controller #1872, sveltos #768
Recover From Rejected Updates via Force Recreate
PolicyRef/KustomizationRef gain a Force option. Server-side apply cannot always reconcile a manifest change: if a field was set by API server defaulting (or is owned by an unknown field manager) and the new manifest introduces a conflicting value, the apply is rejected and no patch can clear it (e.g. a Deployment moving to strategy.type: Recreate while the API server's previously-defaulted rollingUpdate is still set). When Force is set and an apply is rejected with an error only a delete+recreate can resolve, the object is now deleted and recreated instead of surfacing the error. Never applies to CustomResourceDefinitions, since deleting one cascades to every instance of it, and conflicts (already handled by retry-in-place) are excluded.
PRs: libsveltos #642, addon-controller #1877
⚙️ Improvements
Shared, Cached Managed-Cluster Clients
The cluster rest.Config/mapper/discovery-client cache moves from addon-controller-local code into lib/clustercache in libsveltos, so addon-controller, classifier, healthcheck-manager, event-manager, and access-manager all share the same cache instead of each building a fresh client (with a live discovery round-trip) on every call, or managing their own cache independently. The shared cache also adds InvalidateOnAuthError, evicting a cluster's cached client (and the underlying workload-identity cache entry) as soon as the API server rejects credentials with 401/403, instead of waiting for TTL expiry or an explicit cluster delete.
PRs: libsveltos #644, classifier #489, healthcheck-manager #417, event-manager #505, addon-controller #1878, access-manager #352
🐞 Bug Fixes
Dashboard: Cluster Label Changes Not Reflected
SveltosClusterPredicate and ClusterStatusPredicate missed reacting to labels changes, so a cluster relabel wasn't always picked up.
PR: ui-backend #175
classifier: Deleted Cluster Reports Treated as Failures
A ClassifierReport left over from a since-deleted cluster was treated as a hard failure on every reconcile. deployClassifier now checks whether the report's cluster still exists before processing it and skips reports for clusters that are gone, and a new background sweep runs every 5 minutes to remove ClassifierReports whose cluster no longer exists.
PR: classifier #487
Missing FailureMessage on ClusterSummary Delete
When deleting a ClusterSummary failed, the error wasn't reported in FailureMessage, leaving no visible reason for the failure.
PR: addon-controller #1873
Helm Upgrade Force Option Silently No-Op
getHelmUpgradeClient unconditionally set ServerSideApply and ForceConflicts on every upgrade, a combination the Helm SDK rejects outright (cannot use force conflicts and force replace together), so an upgrade with force set failed immediately instead of ever taking effect. ServerSideApply/ForceConflicts are now only enabled when force is not set; when force is set, both are disabled so the delete+recreate path can proceed as Helm expects.
PR: addon-controller #1876
DryRun ClusterReports Left Unpopulated on Resource Errors
When a resource's dry-run apply failed (e.g. a StatefulSet update rejected with an immutable-field error), the failure surfaced correctly on ClusterSummary.Status.FeatureSummaries[].FailureMessage, but ClusterReport.Status.ResourceReports was never written, since processing returned early on the deploy error before reaching the call that persists the report. The failing resource now gets a ResourceReport with an Error action recording the failure (DryRun mode only), and whatever ResourceReports were gathered are persisted before the deploy error is returned, instead of the ClusterReport update being skipped entirely.
PR: addon-controller #1885
🔧 Maintenance
- All components advanced to Cluster API v1.13.4
- All components advanced to Go 1.26.5