Skip to content

feat: Support delaying SveltosCluster removal for cleanup - #384

Merged
gianlucam76 merged 1 commit into
projectsveltos:mainfrom
gianlucam76:sveltoscluster-delete-timer
Sep 17, 2026
Merged

gianlucam76 merged 1 commit into
projectsveltos:mainfrom
gianlucam76:sveltoscluster-delete-timer

Conversation

@gianlucam76

Copy link
Copy Markdown
Member

SveltosCluster deletion can now be delayed via spec.cleanupGracePeriod. When a SveltosCluster is deleted and this field is set, the cluster stays registered, present, with a deletion timestamp, but not yet gone, for that long before it's actually removed.

This closes a gap for clusters that have nothing else holding them open during teardown. A ClusterAPI Cluster stays visible for a while after deletion because its infrastructure provider's own finalizer blocks removal until the underlying VPC/instances/load balancers are actually torn down. That window is what makes it possible to run last-minute cleanup against it. A bare SveltosCluster (used for non-ClusterAPI clusters) has no such finalizer and disappears the instant it's deleted, so nothing gets a chance to react.

With cleanupGracePeriod set, that same kind of window now exists for any SveltosCluster: cleanup automation. For example an EventSource/EventTrigger watching this SveltosCluster with includeDeletingResources: true has a guaranteed amount of time to run before the object actually disappears.

If cleanupGracePeriod is not set, deletion behaves exactly as it does today, immediate.

Usage

apiVersion: lib.projectsveltos.io/v1beta1
kind: SveltosCluster
metadata:
  name: my-cluster
spec:
  cleanupGracePeriod: 10m

SveltosCluster deletion can now be delayed via spec.cleanupGracePeriod.
When a SveltosCluster is deleted and this field is set, the cluster
stays registered, present, with a deletion timestamp, but not yet gone,
for that long before it's actually removed.

This closes a gap for clusters that have nothing else holding them open
during teardown. A ClusterAPI Cluster stays visible for a while after
deletion because its infrastructure provider's own finalizer blocks removal
until the underlying VPC/instances/load balancers are actually torn down.
That window is what makes it possible to run last-minute cleanup against it.
A bare SveltosCluster (used for non-ClusterAPI clusters) has no such finalizer
and disappears the instant it's deleted, so nothing gets a chance to react.

With cleanupGracePeriod set, that same kind of window now exists for any
SveltosCluster: cleanup automation. For example an EventSource/EventTrigger
watching this SveltosCluster with includeDeletingResources: true has a
guaranteed amount of time to run before the object actually disappears.

If cleanupGracePeriod is not set, deletion behaves exactly as it does
today, immediate.

Usage

```yaml
apiVersion: lib.projectsveltos.io/v1beta1
kind: SveltosCluster
metadata:
  name: my-cluster
spec:
  cleanupGracePeriod: 10m
```
@gianlucam76
gianlucam76 force-pushed the sveltoscluster-delete-timer branch from a7718db to d69faf5 Compare September 17, 2026 07:29
@gianlucam76
gianlucam76 merged commit 49610d7 into projectsveltos:main Sep 17, 2026
5 checks passed
@gianlucam76
gianlucam76 deleted the sveltoscluster-delete-timer branch September 17, 2026 07:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant