Editing and applying

CodeMirror 6. When kweblens has a schema for the kind, the plain YAML language mode is replaced by a schema-aware one that supplies completion, hover and linting from that schema.

The schema is the cluster’s own. GET /api/v1/clusters/{id}/schema?resource={kind} reads /openapi/v3/…​ off the API server for the kind’s group-version, rewrites the $ref locations into draft-07 form, and returns the target kind inlined at the root with every other schema in that group-version under definitions.

Two consequences of it being the cluster’s schema rather than a bundled one:

The schema is cached per cluster and group-version with a 10-minute TTL on a monotonic clock, and is invalidated for a cluster when that cluster’s client is replaced or removed — so re-pointing a cluster id cannot leave the editor completing against the previous API server.

Fetching the schema is best-effort. If it fails, you get a plain YAML editor rather than an error.

A structured editor generated from the same schema. The YAML draft stays the single source of truth: the form parses the draft, edits nodes in place and writes the document back, so ordering, comments and any fields the form does not model survive a round trip.

It renders:

Field widgets come from the schema: booleans get a switch, integers a number input, enums a select populated from the schema’s own enum, everything else a text input.

Fields the API server will not let you change are shown read-only with the reason, rather than accepting an edit that would be rejected — a workload’s pod selector and a Service’s clusterIP are the common cases.

For a set of well-known workload and networking kinds the fields are a curated list; for anything else the form falls back to discovering scalar fields directly under spec, capped at 30. With no schema at all, the Form tab has no fields to offer.

If the draft is not parseable the tab says so plainly — Can’t parse the YAML — fix it in the Editor tab to use the form. — instead of silently showing an empty form.

The schema linter’s findings, listed as Line N plus the message. The tab label carries a count badge, which turns red when any finding is an error rather than a warning. Clicking a finding jumps to the Editor tab.

The empty state is No schema warnings.

This tab shows two diffs side by side, because "is my edit what I meant" and "will the cluster agree" are different questions and both are worth asking.

Left — Your edit. Caption: Edited YAML against what was loaded. This is what you changed. A diff of the draft against the text the editor opened with. This is entirely local; it never touches the cluster.

Right — What the cluster would store. A real request: POST /api/v1/clusters/{id}/apply/dry-run, which the server issues as dryRun().forceConflicts().serverSideApply() — dryRun=All, so the manifest goes through the whole chain and the object that would have been persisted is returned and then discarded.

Three things live in the gap between the two diffs, and none of them is visible from the left one:

Both sides of the right-hand diff are normalised the same way before comparison, so the diff is a diff rather than a wall of managedFields.

The preview is fetched when you open the tab, and re-fetched when the draft has moved on since the last answer — not on every keystroke, because it is a real round-trip. A Re-check button forces it. An answer that arrives after you have typed further is discarded rather than shown against the wrong draft.

The caption tells you which of five states you are in:

Selecting rows reveals a bar showing N selected with Delete and Clear. One confirmation covers the whole set, then kweblens deletes them one at a time through the same per-object endpoint — there is no server-side bulk delete, so each object gets its own audit entry.

Partial failure is reported honestly rather than as a single red banner: you get Deleted X of Y …; N failed, with the first few reasons named and the rest counted.

The loop distinguishes two kinds of failure: