Cores

The Cores page is where the PADAS UI registers Core instances: each row stores connection settings (host, port) and the bearer token the UI uses to call that Core’s API.

Pipeline and workload placement are not configured here. Use Management → Cores and Management → Pipelines to assign pipelines and related work to an engine. Removing a Core row here only unregisters it in the UI; it does not stop Core on the host—confirm nothing in Management still references that registration before you delete.

Overview

This page lets you:

• Register Core instances the console can manage.
• Store host, port, and account token for UI-to-Core API calls.
• Configure API authentication (Bearer token from each Core host).

This page does not manage workload placement, pipeline assignment, or runtime scheduling.

Cores list page

Open Cores (/cores). Use Create to add a row; use row Actions for view, edit, clone, or delete. Column filters sit under the headers; the footer shows totals and paging.

The registered Cores list.

On these Configurations screens the layout is the same: Search and Create in the toolbar, Download / Upload for registry JSON (a full bundle can be imported from any tab), then a grid with filters on the row under the headers.

Each row has View (read-only), Edit, Clone, and Delete. Select multiple rows when you need bulk delete. Created and Updated time may show as narrow strips; use the control at the side of the table to expand or collapse those columns.

Column	Description
ID	Stable identifier for this Core row in the UI database.
Name	Display label chosen at registration.
Host	Hostname or IP the UI server uses for the Core API.
Port	Core API port (typically 8999).
Created Time / Updated Time	Row create and last update timestamps.
Actions	View, Edit, Clone, Delete.

Create and edit

1. Open Cores and choose Create (or Edit on an existing row).
2. Enter Core Name, Host, Port, and on create a non-empty Account Token (see Token).
3. Optionally add a Description via + Add description.
4. Save. Then follow Verification.

The Create Core form.

Field	Role
Core Name	Unique label; drives display name and a derived row id. Immutable after create.
Host	Core API hostname or IP as seen from the UI server (default in the form is often localhost).
Port	Core API port; must match Core [api] (default 8999).
Account Token	Bearer secret for Authorization: Bearer … to this Core’s API.
Description	Optional operator notes.

Field	Create	Edit
Core Name	Required	Read-only
Host	Required	Editable
Port	Required	Editable
Account Token	Required (non-empty)	Optional — blank keeps the stored token; new value replaces it

The Core instance must have started at least once so service-account.token exists on the engine before you copy a token into the form. Path on the Core host: $PADAS_HOME/data/security/service-account.token (for example /opt/padas/core/data/security/service-account.token when PADAS_HOME=/opt/padas/core).

Connectivity and authentication

The UI server calls each Core’s HTTPS API at https://<host>:<port>/api/v1/... (or http:// when Core TLS is off). Host and Port must match that Core’s bind and TLS settings (Runtime configurations).

Deployment	Host guidance
UI and Core on the same machine	localhost or 127.0.0.1 is usually correct from that OS.
UI in Docker / Kubernetes, Core on the host	Do not use 127.0.0.1 from inside the container for the host’s Core. Use a LAN IP, host.docker.internal where supported, or a DNS name the pod can resolve.
TLS	If Core uses a self-signed cert, the UI JVM/process must trust it (truststore, corporate CA, or documented insecure mode)—otherwise save or status checks fail.
Firewall	Allow inbound to Core’s API port (default 8999) from the UI host or pod network, not only from an operator laptop.

Token

Source — On the Core host, read service-account.token and paste the JSON token field as Account Token.

Rotation — After rotation on Core, open Edit for that row and paste the new secret (or leave blank to keep the previous stored value unchanged).

Security — Treat host, port, and token as secrets. Restrict Core API exposure to trusted networks; prefer TLS. Rotate tokens after compromise. Do not assume localhost in the UI means the same host when the UI runs in containers.

Verification

After you save a Core registration:

1. Save the row and wait for the UI to persist it.
2. From a host on the same network path as the UI (or from the UI server itself), confirm TCP/TLS reachability to https://<host>:<port>.
3. Call GET /api/v1/status with Authorization: Bearer <token> (same token as in the form).
4. Confirm 200 and expected payload (e.g. healthy system.status per your environment).
5. In the UI, confirm the Core row shows expected health/status if your version surfaces it.

References: Installation — Linux → Validate services, Quickstart: Core + UI → verify API.

For multiple Cores, use a distinct Core Name per row, the correct Host/Port per instance, and each instance’s own service-account.token.

Troubleshooting

See Troubleshooting & Logs → UI registration and Core connectivity for the consolidated symptom table.

Related reading

• Quickstart: Core + UI → Register a Core
• Quickstart: Core only — if you applied the API-only quickstart to the same engine, clean it before the UI flow
• Runtime configurations — API port, TLS, auth
• Security
• Naming conventions — registry object naming (separate from Core registration labels)