Baseline Overrides

What the baseline is

PodWarden defines a code-defined baseline — a set of expected values for Longhorn storage settings, k3s server arguments, and required Kubernetes namespaces that every PodWarden-provisioned cluster should have. The drift detector compares live cluster state against this baseline every 15 minutes and surfaces mismatches as system messages.

The defaults are conservative fleet-wide values that work for most clusters. When a cluster legitimately needs a different value — for example, a single-node dev cluster where some HA defaults are meaningless — you can override individual keys without changing the global defaults that every other cluster uses.

Shipped in the 2026-05-01 release as part of the cluster baseline persistence feature (#708 + #713).

What you can override

Three resource types are supported:

Resource type	What it covers	Example keys
`longhorn_setting`	Longhorn global settings	`replica-soft-anti-affinity`, `orphan-resource-auto-deletion`, `concurrent-replica-rebuild-per-node-limit`
`k3s_arg`	k3s server config.yaml arguments	`kube-controller-manager-arg`, `kubelet-arg`
`namespace`	Required namespaces that must exist	`podwarden-system`, `podwarden-backup-system`, `longhorn-system`

Overrides are validated against the canonical defaults at the time of creation. You cannot override a key that is not in the baseline — this is a typo guard. If you need a key added to the baseline, contact your PodWarden administrator.

Viewing overrides

Navigate to a cluster's detail page and open the Baseline tab. The tab shows:

The effective baseline for this cluster — the merged result of global defaults and any per-cluster overrides
A table of active overrides showing the resource type, key, override value, reason, and who created it
The global defaults (read-only) alongside overridden values so you can see what changed

Adding an override

Go to Clusters → [cluster name] → Baseline tab
Click Add Override
Select the resource type (longhorn_setting, k3s_arg, or namespace)
Select or type the key — the dropdown shows only canonical keys for the selected resource type
Enter the override value — must be a non-empty string
Optionally add a reason (recommended — helps future operators understand why the override exists)
Click Save

The override takes effect on the next drift detection cycle (up to 15 minutes). If a system message already exists for the key you just overrode to match the live value, it will auto-resolve within 2 clean cycles.

Removing an override

From the Baseline → Overrides table, click the delete icon on the row you want to remove. The cluster will revert to the global default for that key on the next drift detection cycle. If the live cluster value differs from the global default, a new drift finding will be emitted.

Bringup-time apply

When a new cluster completes provisioning (greenfield bringup), PodWarden automatically applies the effective baseline — all global defaults plus any overrides already configured for that cluster — before the cluster enters service. This means:

Required namespaces are created
Longhorn settings are patched to baseline values
k3s server arguments are validated

This happens as part of the provisioning flow. You do not need to manually trigger it.

Permission model

Action	Minimum role
View baseline and overrides	operator
Create or delete an override	operator

Viewers cannot access the Baseline tab.

API reference

For automation and scripting, overrides are available via REST:

Method	Path	Description
`GET`	`/api/v1/clusters/{cluster_id}/baseline-overrides`	List all overrides for a cluster
`POST`	`/api/v1/clusters/{cluster_id}/baseline-overrides`	Create or update an override
`DELETE`	`/api/v1/clusters/{cluster_id}/baseline-overrides/{override_id}`	Delete an override

The POST body requires resource_type, resource_key, and override_value. reason is optional but recommended.