Operations journeys

Table of Contents

The installation has a life of its own, and somebody has to be able to look at it: which services are up, what the compute grid is doing, whether the message bus is moving, what the logs recorded, and which builds sit under it all. These journeys are the operator's view of a running system, and they replace the telemetry and super-admin windows of the legacy ores.qt client.

Five journeys belong to the system administrator. The last belongs to any signed-in person: the versions screen answers "what am I talking to", which a member asks as often as an administrator. Who reaches the screens sets out what each of the three signed-in contexts sees. Almost every journey here only reads: samples, summaries or lines that the installation writes about itself. The exception is the market data feeds journey, which starts and stops a feed. That is also what keeps them cheap to build: the server already stores everything they show, with the gaps recorded below.

1. Journeys

Journey Actor Gist
See the running services system administrator Every service the installation expects, with its instance count, state and version; rows never disappear
Watch the compute grid system administrator The host and work summary, one row per node, and the compute wrappers that report for those nodes
Watch the message bus system administrator The NATS server's vitals and one row per stream: messages, bytes and consumers over time
Read the telemetry logs system administrator The lines behind a symptom, found by time, level, source, component, tag or session
Check the versions and the database any signed-in person The client build, the server build, and the database fingerprint
Keep the market data sources running system administrator Each source with its adapter state, the ids it serves and rejects, its last tick and its quality drops

2. Who reaches the screens

Menu structure replaces the rule below. Operations is not one kind of user's area. It is drawn for anyone who holds the read of one of its screens, and each screen is guarded by its own read. The table below states the position before that change.

The shell draws the line with an area, not with a permission on a screen: the system-administration menu carries Operations and no other menu does, and a screen that belongs to another mode is absent rather than disabled, because it is not a door that person may open later. The four installation screens are therefore the super administrator's alone, and the versions screen is every signed-in person's, because the question it answers is not a privileged one.

Actor Context Operations area Installation screens Versions screen
System administrator SuperAdmin role, acting from the system tenant; system administration mode Offered; it carries the five journeys All four, installation-wide Offered, from the area
Tenant administrator Signed in inside their own tenant; tenant administration mode Absent Unreachable Offered, in every mode
Regular user Any other signed-in person; the shared application context Absent Unreachable Offered, in every mode

The footer that states the client and the server rides on every screen in every mode, so the first step of the versions journey is every person's. The application row covers a privileged party user and a regular one alike: what separates them is the permissions they hold, not the mode, and neither reaches the Operations area.

3. Where the legacy screens went

The legacy ores.qt client carried a telemetry window and a set of super-admin windows. Every one of them has a disposition, so no screen is lost by accident. Covered means a journey carries it; changed means a journey carries it in a new form; deferred means it has no journey yet, and none is planned here; dropped means a web client does not need it.

Legacy screen What it did Disposition
TelemetryMdiWindow A session tree with session details, and a live log view beside it Covered: the sessions by Audit sign-ins, the logs by Read the telemetry logs
SessionAuditDialog One session's audit: activity, bytes and details Covered by Audit sign-ins, which keeps the live byte samples
AboutDialog Version, build metadata and system info, with a Database row hardcoded to "not connected" Covered by Check the versions and the database; the Database row is the gap that journey records
TelemetrySettingsDialog Logging settings for the desktop client: level, file and console sinks Dropped: it configures the desktop client, not the installation
ConnectionBrowserMdiWindow The desktop client's saved connections Dropped: the browser holds one connection, so there is no roster to browse
EventViewerDialog The desktop client's internal event bus Deferred: a developer tool with no user goal; the telemetry logs carry what a person needs
ShellMdiWindow The embedded REPL Dropped: the shell runs as its own client
ComputeDashboardMdiWindow The grid summary Covered by Watch the compute grid
HostMdiWindow, HostDetailDialog The host registry and one host's details Covered in part: the node rows by Watch the compute grid; host maintenance by Extract the ores.compute user journeys
QueueMonitorMdiWindow, QueueChartWindow The client's own message queue, and one stream's charts Changed: Watch the message bus reads the NATS stream samples, because the installation runs no queue of its own
AppVersionMdiWindow, AppVersionDetailDialog The app version registry Deferred to Extract the ores.compute user journeys
ComputeConsoleWindow The BOINC-style console: tasks, transfers and hosts Covered in part: the Hosts tab by Watch the compute grid; tasks and transfers by Extract the ores.compute user journeys
SchedulerMonitorMdiWindow Live per-job scheduler status Deferred: the scheduler's journeys are a later extraction

4. Related

5. See also

  • UX — the structure note that orders this cluster, and where to read this page in it.

Emacs 29.3 (Org mode 9.6.15)