bug: deploymentType Local and management cluster - #1892
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.
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
1 participant
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