Use case
PreDeployChecks, ValidateHealths, PreDeleteChecks, and PostDeleteChecks (all backed by the ValidateHealth type) currently let you gate a deployment or deletion on the declarative state of the managed cluster: select some resources (Group/Version/Kind/Namespace/LabelFilters) or a Prometheus query (MetricSource/MetricQueries), then evaluate a Lua Script or an EvaluateCEL rule against what's already there.
What exists today
ValidateHealth selects resources by Group/Version/Kind/Namespace/LabelFilters, and/or pulls in metrics via MetricSource/MetricQueries.- It evaluates either a Lua
Script (function evaluate() ... return { health = ..., message = ... } end) or an ordered list of EvaluateCEL rules against the selected objects/metrics.
- Both are strictly read-only observation of state that already exists. Neither can trigger a workload and wait on its result.
What's missing
A way to specify, as an alternative to Script/EvaluateCEL, a Job (or Pod) template that Sveltos deploys into the managed cluster, waits for completion up to a timeout, and treats as pass/fail based on the Job's outcome. This would apply at the same four existing lifecycle points (PreDeployChecks, ValidateHealths, PreDeleteChecks, PostDeleteChecks) — no new lifecycle concept, just a new way to satisfy the existing one.
Example use cases:
- PreDeployChecks: run a Job that actively verifies a prerequisite service responds correctly, not just that the
Service object exists.
- ValidateHealths: run a smoke-test Job against a newly deployed endpoint (real HTTP request, expected response) instead of only checking
Deployment/Pod status fields.
- PreDeleteChecks: run a backup Job to completion before teardown is allowed to proceed.
- PostDeleteChecks: run a Job that actively probes for orphaned external resources (e.g. a cloud load balancer) rather than only checking Kubernetes-visible state.
Possible approach
Add an optional Job-template field to ValidateHealth, alongside and mutually exclusive with Script/EvaluateCEL. When set, Sveltos would create the Job in the managed cluster, wait for completion up to a timeout, treat Complete as pass and Failed as fail, surface the failure (e.g. pod logs or a message) the way failures already surface elsewhere in ClusterSummary status, and clean up the Job/Pods after evaluation. Not attached to this specific shape, just to the underlying capability.
Use case
PreDeployChecks,ValidateHealths,PreDeleteChecks, andPostDeleteChecks(all backed by theValidateHealthtype) currently let you gate a deployment or deletion on the declarative state of the managed cluster: select some resources (Group/Version/Kind/Namespace/LabelFilters) or a Prometheus query (MetricSource/MetricQueries), then evaluate a LuaScriptor anEvaluateCELrule against what's already there.What exists today
ValidateHealthselects resources byGroup/Version/Kind/Namespace/LabelFilters, and/or pulls in metrics viaMetricSource/MetricQueries.Script(function evaluate() ... return { health = ..., message = ... } end) or an ordered list ofEvaluateCELrules against the selected objects/metrics.What's missing
A way to specify, as an alternative to
Script/EvaluateCEL, a Job (or Pod) template that Sveltos deploys into the managed cluster, waits for completion up to a timeout, and treats as pass/fail based on the Job's outcome. This would apply at the same four existing lifecycle points (PreDeployChecks,ValidateHealths,PreDeleteChecks,PostDeleteChecks) — no new lifecycle concept, just a new way to satisfy the existing one.Example use cases:
Serviceobject exists.Deployment/Podstatus fields.Possible approach
Add an optional Job-template field to
ValidateHealth, alongside and mutually exclusive withScript/EvaluateCEL. When set, Sveltos would create the Job in the managed cluster, wait for completion up to a timeout, treatCompleteas pass andFailedas fail, surface the failure (e.g. pod logs or a message) the way failures already surface elsewhere inClusterSummarystatus, and clean up the Job/Pods after evaluation. Not attached to this specific shape, just to the underlying capability.