Repository navigation
bug: deploymentType Local and management cluster - #1892
Merged
Merged
Conversation
Fixes a bug where a SveltosCluster representing the management cluster itself (self-managed) matching a ClusterProfile could cause its ClusterSummary to delete resources deployed by other, unrelated ClusterSummary instances. When a PolicyRef/KustomizationRef uses deploymentType: Local, resources are deployed into the management cluster and tagged with a projectsveltos.io/clustersummary annotation identifying the owning ClusterSummary, so stale-resource cleanup only removes what that specific ClusterSummary deployed in the management cluster. That scoping was only ever applied to the "clean the management cluster" pass. The "clean the remote/managed cluster" pass never set it, which was harmless as long as the remote cluster was a distinct physical cluster from the management cluster. When the managed cluster is a self-managed SveltosCluster (its remote client/config resolve back to the management cluster itself), the remote-cluster cleanup pass ends up scanning the management cluster with no scoping at all, and deletes every same-GVK, same-ClusterProfile resource not present in its own (often empty, since all its policies are Local) desired state, including resources deployed by other ClusterSummary instances via Local. Fix: - The clustersummary annotation is now set on every deployed resource, not only ones deployed via Local. - Stale-resource scanning now checks this annotation on both cleanup passes, but only as a protective signal: a resource is skipped only when it's explicitly annotated for a different ClusterSummary. A resource with no annotation at all (deployed by a version before this change) still falls through to the existing ownership/reference checks, so upgrades don't leave pre-existing resources permanently undetectable as stale.
3 of 4 tasks
gianlucam76
added a commit
that referenced
this pull request
Oct 9, 2026
* fix: Management cluster stale pass only removes resources it deployed When a Resources feature is deployed, the addon-controller also runs a cleanup pass against the management cluster (isMgmtCluster=true, with its own service account) for every GroupVersionKind the ClusterSummary has deployed, even when the ClusterProfile has no deploymentType: Local reference. In v1.13.0 that pass only considered resources carrying the clustersummary annotation of this very ClusterSummary, and that annotation was set on Local deploys only, so it could never touch anything but what this ClusterSummary had deployed locally. Since v1.14.0 (#1892) the annotation became a protective signal for both passes: a resource is skipped only when it is annotated for a different ClusterSummary, and a resource with no annotation falls through to the profile ownership check. That is right for the managed cluster pass, which has to detect resources deployed before the annotation existed, but it loosened the management cluster pass. A resource in the management cluster owned by a (Cluster)Profile with the same name, but deployed by someone else, is now considered stale and deleted. This happens when the management cluster is itself managed by another Sveltos instance deploying the same profile, or after a self-managed cluster was removed. The delete is typically forbidden for the addon-controller (for instance a Namespace, a PersistentVolume or an EventTrigger), so the failure repeats forever and, because the cleanup returns on the first error, the managed cluster pass and the rest of the post-processing never run: the feature stays in Provisioning. The management cluster pass requires again the clustersummary annotation of this ClusterSummary, as in v1.13.0. The managed cluster pass is unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> * chore: management cluster stale pass ignores resources from a parent Sveltos instance Adds a unit test for undeployStaleResources in the management cluster pass (isMgmtCluster=true). The management cluster can itself be a managed cluster of a parent Sveltos instance. The test creates a resource that looks like it was deployed by that parent: deploymenttype: Remote, another cluster's clustersummary value, and the same owner-kind/owner-name as the local ClusterProfile. It checks that the resource is not removed, while a resource this ClusterSummary deployed with deploymenttype: Local and its own clustersummary value is removed. This PR also advances cluster-api to v1.14.3 --------- Co-authored-by: Gianluca Mardente <mgianluc@ciroos.ai> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes a bug where a SveltosCluster representing the management cluster itself (self-managed) matching a ClusterProfile could cause its ClusterSummary to delete resources deployed by other, unrelated ClusterSummary instances.
When a PolicyRef/KustomizationRef uses deploymentType: Local, resources are deployed into the management cluster and tagged with a projectsveltos.io/clustersummary annotation identifying the owning ClusterSummary, so stale-resource cleanup only removes what that specific ClusterSummary deployed in the management cluster. That scoping was only ever applied to the "clean the management cluster" pass. The "clean the remote/managed cluster" pass never set it, which was harmless as long as the remote cluster was a distinct physical cluster from the management cluster.
When the managed cluster is a self-managed SveltosCluster (its remote client/config resolve back to the management cluster itself), the remote-cluster cleanup pass ends up scanning the management cluster with no scoping at all, and deletes every same-GVK, same-ClusterProfile resource not present in its own (often empty, since all its policies are Local) desired state, including resources deployed by other ClusterSummary instances via Local.
Fix:
Fixes #1891