Cores

Management → Cores is the workload placement and deployment lifecycle surface: you assign sources, tasks, and sinks to one PADAS Core per inventory row, deploy configuration revisions to the engine, and read deployment state and deployment drift. It does not author pipeline topology or replace live runtime graphs—that work lives under Configurations and Control Tower.

Architecture context

Layer	Role
Control plane	Stores assignments, drives deploy to each Core, and surfaces deployment drift markers.
Core runtime	Runs deployed workloads after runtime activation; reports status back to the UI.
This page	Orchestrates desired state → deployed state for per-component placement—not stream processing itself.

warning

• Assigning workloads saves placement; it does not deploy revisions to the Core.
• Deploying pushes deployed state; it does not start runtime execution.
• Runtime activation (start / stop) is separate—use Advanced after deploy.

What this page manages

Topic	Where
Component placement for sources, tasks, sinks	This page — which workloads belong on which Core.
Pipeline topology (graph authoring)	Pipelines
Pipeline assign + Deploy All	Management → Pipelines
Engine registration (Host / Port / credentials directory)	Cores
Live execution graph and pipeline-level controls	Control Tower

Assignment lifecycle

At a high level: define registry objects → bind them to a Core → deploy → activate execution elsewhere.

Step	Meaning
Placement	Assign saves which components run on this Core (desired state in the control plane).
Deploy	Row Deploy or Assign and Deploy pushes revisions so deployed state matches desired state.
Activation	Advanced start / stop controls runtime execution after a successful deploy.

Assign vs deploy vs start

Action	Updates placement	Deployed on Core	Runtime activation
Assign	Yes	No	No
Assign and Deploy	Yes	Yes	No
Deploy (row)	—	Yes (pending slices)	No
Start / Stop (Advanced)	—	Uses last deploy	Yes

Core inventory

Scan rows for connectivity, bound workloads, and deployment drift before incident deep dives.

Column	Use
Core ID / Name	Stable row identity and operator label.
Host / Port	Management endpoint—should match Cores registration.
Sources / Tasks / Sinks	Workload tags bound to this Core; empty implies unfinished placement.
Actions	Assign opens the modal; Deploy pushes pending changes for this Core only.

Core inventory and deployment state.

Filters and search behave like other Management grids.

Working with assignments

Open Assign to choose sources, tasks, and sinks for the row.

Control	Effect
Assign	Saves placement only—desired state updates; no push to the engine.
Assign and Deploy	Saves placement and runs deploy so the Core receives updated definitions.

Modal flow: pick components → Assign or Assign and Deploy. Until deploy completes, the runtime keeps the previous deployed revision for affected workloads.

Component assignment workflow.

Deployment drift

Needs deploy means deployed state on the Core differs from desired state for that component—the registry or placement moved ahead of what the engine loaded.

Behavior	Detail
Scope	Drift is per component tag; tooltips usually name the stale object.
During deploy	Runtime execution can keep using the prior deployed revision for that slice until deploy finishes successfully.
Operator response	Use row Deploy or modal Assign and Deploy; clear warnings before assuming runtime parity with the registry.

Deployment drift on assigned components.

Relationship to pipelines

Surface	Responsibility
Cores	Workload placement — sources, tasks, sinks → one Core per row; per-component deploy.
Pipelines	Pipeline deployment — which pipeline attaches to which Core(s); Deploy All for pipeline topology.
Control Tower	Runtime execution visibility — live topology, stage health, graph-level actions on the selected Core.

Pipelines orchestrate graph-level rollouts; Cores reconcile component-level placement and deployment state. Both may be required before data flows end-to-end.

Activation after deploy

Deployment alone does not start workloads. After deployed state is current, use Advanced (Tasks, Sources, Sinks) for runtime activation. Control Tower complements this with pipeline execution visibility and controls when pipelines are attached.

Operational workflow

1. Verify Core connectivity — Host / Port align with Cores.
2. Review assigned workloads — tags show sources, tasks, sinks on each row.
3. Check deployment drift — clear needs deploy before trusting deployed state.
4. Deploy pending changes — row Deploy or Assign and Deploy before blaming runtime issues.
5. Start workloads — Advanced when execution should run.
6. Observe behavior — Control Tower and Pipelines status for graph-level posture.

Related pages

• Cores — register engines
• Pipelines — registry pipeline topology
• Management → Pipelines — pipeline assign and Deploy All
• Management → Advanced — workload start / stop
• Control Tower — live graph and runtime visibility