Skip to content
Spinoza

Documentation

Browsing and editing

One informer-backed view per resource type, and an inspect drawer that edits the live object.

How the tables are built

Discovery builds a catalog of what the cluster serves. Each type you subscribe to gets a dynamic informer whose cache is projected into rows, so a CRD needs no per-type code to get a working view.

The socket sends one snapshot and then deltas keyed by uid. Informers strip managedFields before caching, so the rows stay small.

  • A field-aware filter, completed from what the cluster actually reported.
  • Namespace scope, carried across views.
  • A badge on objects that are failing, before you open one.
  • Bulk restart and bulk delete from a selection.

Rows answer to the keyboard: arrows move between them, Home and End jump to the ends, Enter opens the inspector on the row, Space selects it for a bulk action, and Cmd or Ctrl with Enter opens the row and moves you into the inspector. Settings publishes the full list under Keyboard, and ? shows it from anywhere.

Saved views

A filtered table can be kept under a name: the filter, its columns, its namespace and its kind. Saved views open from the command palette.

In cluster mode each person's views are their own, and an admin can publish one for everybody.

The inspect drawer

Metadata, conditions, events and the live YAML in Monaco, with completion driven by the cluster's own OpenAPI so your CRDs are covered too. Changes go back through server-side apply.

Apply sends the object back with the resourceVersion you read, so a draft built on a read the cluster has since moved past is refused rather than written over the newer object. Delete names the object you inspected by its UID, so a replacement that reused the name is left alone.

A draft you are editing survives a background reload, and the browser's Back button asks before it discards one.

Secret values arrive masked. Reveal them one key at a time, and the reveal drops the moment you select something else. Masking is a screen guard, not access control: the values are in the response the browser received, so anyone allowed to read a Secret can also read it from the developer tools.

Comparing

Any object can be put beside the same object in another context, or a whole kind can be compared at once with a verdict per object: same, differs by so many lines, or present on only one side.

Both sides lose status, managedFields and the rest of what the server assigns first, so what differs is what you authored. The result names the fields it left out, so nothing disappears from the comparison without saying so.

Rollout revisions

A Deployment, StatefulSet or DaemonSet lists what it rolled out and which revision is running now. Any two revisions can be diffed, with the server's own fields stripped first.

Undo goes back to a chosen revision. It asks the apiserver first and is greyed out with the reason when the cluster would refuse it, and on a protected cluster it asks for the name typed out.

Write actions

  • Scale, rollout restart and undo.
  • Cordon and uncordon.
  • Drain, which shows its eviction plan first: what it evicts, what it leaves, what it blocks and why.
  • CronJob suspend, resume and run now.

A cluster you mark as protected requires the object name typed out before a destructive action runs. Deleting, draining, scaling to zero and uninstalling are the actions it covers.

A cluster you have not opened before offers protection once, as a notice you can accept or dismiss without leaving what you were doing. The answer is remembered for that cluster, and the padlock in the top bar turns it on or off later.

A write whose answer never came back is reported as unknown, not as failed. Check the object before trying again: the change may already be on the cluster, and its History entry will say.

History

Every change Spinoza makes is kept per cluster, with what it touched, who asked for it and whether the cluster allowed it.

The same view can record a timeline of what the cluster itself did, for workloads or for every kind. It keeps 7 days by default and at most 90. A batch that could not be written leaves a row saying how many changes went missing and when, so a gap in the timeline stays visible.