Pulse Operator

CURRENT IMPLEMENTATION // INDEPENDENT OPERATOR VERSION

Deploy and reconcile Pulse through an OpenShiftPulse custom resource.

What you can do

Capabilities depend on configuration, permissions and the deployed image pair. Consult current source and operational guides.

Reconcile the installation

The custom resource configures UI, agent, PostgreSQL and optional MCP/Temporal components. Inspect the current CRD and README for supported fields and defaults.

Manage image compatibility

Agent and UI deploy as a matched pair. Operator versioning is independent; an optional minimum operator version checks the running operator build, not database schema compatibility.

Publish OLM artifacts

The tag workflow builds operator, bundle and file-based catalog images. It updates the bundle CSV for the tag and renders available release history into the catalog.

Inspect real cluster prerequisites

The explicit-context acceptance runner observes component ownership, rollout readiness, image IDs and PostgreSQL policy. Optional disposable-namespace probes test actual connectivity and selected mutations.

Readiness and recovery evidence

A ready installation is a prerequisite, not evidence that Pulse diagnosed or repaired an incident. The runner reports incomplete overall acceptance even when its requested observations pass. Real browser, provider, authorization and recovery evidence must be collected separately.

Crashloop, failed rollout and pending-pod acceptance must preserve diagnostic observations, the exact approved target/change, execution results and fresh recovery measurements. Rejected or unverifiable operations stay unresolved.

Operational guides

These links open current repository documentation. Historical plans and designs describe proposals, not current operational guarantees.

Install and configure

Custom resource schema

Cluster acceptance guide

Acceptance runner

Release workflow