Skip to content

Releases: projectsveltos/clusterinventory-controller

Release list

v1.13.0

Choose a tag to compare

@gianlucam76 gianlucam76 released this 27 Jul 16:39
5274afe

🚀 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](https://github.com/projectsveltos/event-ma...

Read more

v1.11.1

Choose a tag to compare

@gianlucam76 gianlucam76 released this 13 Jun 15:38
d086057

🚀 New Features

Health Checks: Metric-Based Validation
ValidateHealth now supports querying a Prometheus-compatible endpoint as an additional data source. Named scalar values are exposed to the Lua evaluate() function via a metrics table, enabling checks such as "error rate below 5 %". In push mode the endpoint must be reachable from the management cluster; in pull mode the sveltos-applier agent running inside the managed cluster reaches it directly via in-cluster DNS.
PR: addon-controller #1816 (projectsveltos/addon-controller#1816)

Kubernetes Events for Deployment Failures
The addon-controller now raises Kubernetes Warning events to make failure causes immediately visible via kubectl describe or any event-watching tool. Events are emitted for conflicts, missing referenced resources, template instantiation errors, and when the controller gives up after reaching the maximum consecutive failure count.
PR: addon-controller #1815 (projectsveltos/addon-controller#1815)

Dashboard: Cluster Deployment Health Signals
The cluster list now surfaces deployment state at a glance. An amber alert icon appears when one or more profile deployments are failing; a blue clock icon appears when deployment is actively in progress with no failures. The ui-backend computes these signals as O(1) in-memory indexes updated by the existing ClusterSummary watcher, so no per-request scanning is required.
PRs: dashboard #173 (projectsveltos/dashboard#173), ui-backend #167 (projectsveltos/ui-backend#167)

HealthCheck: Surface "No Resources Found" as a Degraded Status
When a HealthCheck's resource selectors matched nothing, the resulting HealthCheckReport was silently empty and sveltosctl show resources showed nothing. The Lua evaluate() function can now detect an empty resources table and return a top-level degraded status (e.g. "No deployments found in namespace metrics"), which is surfaced in the report and in sveltosctl.
PR: sveltos-agent #489 (projectsveltos/sveltos-agent#489)

MCP Server: Classifier Pipeline Analysis Tool
A new tool has been added to the Sveltos MCP server to analyze classifier pipelines, making it easier to inspect and reason about classifier configuration via AI-assisted workflows.
PR: mcp-server #55 (projectsveltos/mcp-server#55)

Shard-Controller: Patch Support
A new --shard-components-config flag accepts the name of a ConfigMap in the Sveltos namespace. The ConfigMap holds one or more patches (JSON6902 or strategic-merge) that are applied to the five Deployments shard-controller creates per shard. Target selectors allow a single ConfigMap to patch only specific components. When the ConfigMap changes, a dedicated reconciler re-deploys all active shards immediately so patches take effect without restarting shard-controller.
PR: shard-controller #216 (projectsveltos/shard-controller#216)


🐞 Bug Fixes

addon-controller: Logging, Pull-Mode Status Handler, Helm Data Race, and Dependency Manager
Fixed a logging mistake where cluster name was populated with the cluster namespace in two places. Corrected the pull-mode agent status handler, which could reach a nil dereference when the agent returned an error without a status payload. Fixed a data race in the Helm chart manager where a shared map was read without holding the mutex. The dependency manager's background update loop now snapshots work, releases the write lock before making API calls, and re-acquires it only to clear completed entries — unblocking concurrent reconcilers. Its startup rebuild loop now waits 5 seconds between retries instead of spinning at full speed on API errors.
PR: addon-controller #1823 (projectsveltos/addon-controller#1823)

sveltos-applier: ClassifierReport Retry, Discovery Loop, and Namespace Client Reuse
ClassifierReports were silently marked as delivered even when the push to the management cluster failed, so they were never rld also continue with an empty Classifier object on non-NotFound API errors. The discovery retry loop in the REST mapperrefresh executed exactly once regardless of the loop variable, causing immediate failure on transient API server slowness. A new Kubernetes client — and with it a new HTTP connection pool — was being created for every single resource that needed a namespace ensured; it is now
created once per reconciliation pass.
PR: sveltos-applier #89 (projectsveltos/sveltos-applier#89)

sveltos-agent: Handful Bugs in the Evaluation Package
Nine bugs in the evaluation package have been corrected.
PR: sveltos-agent #490 (projectsveltos/sveltos-agent#490)

ClusterProfile deletion no longer stalls (addon-controller #1829 (projectsveltos/addon-controller#1829))
Fixed a bug where deleting a ClusterProfile could get stuck indefinitely. The allMatchingProfilesProcessed check was not skipping other profiles that were themselves already being deleted, causing the controller to wait forever for work that would never complete.

MCP compare-clusters tool reliability (mcp-server #57 (projectsveltos/mcp-server#57))
Corrected several issues in the compare_managed_clusters MCP tool. A not-found cluster now surfaces a clear error instead of silently returning an empty result. Additionally, when a cluster exists but its ClusterConfiguration has not yet been created (resources still deploying), the tool now returns a non-fatal warning in the output rather than returning misleading empty comparison data.

Spurious pending-updates indicator in the UI (ui-backend #171 (projectsveltos/ui-backend#171))
Fixed incorrect cluster status reporting in the UI backend. A cluster was wrongly flagged as having pending updates when a profile matched it and that profile had declared dependencies. The status is now computed correctly in those cases.


🔧 Maintenance

  • All components advanced to Go v1.26.4
  • All components advanced to golangci-lint v1.12.1