feat(ops): add ops-hub service inventory now view (CUST-WP-0047)
Seed a non-secret service inventory (environments, hosts, clusters, services, endpoints, access paths, evidence, gaps) with a JSON schema, a renderer, and a generated service-catalog view. Adds the `make ops-inventory-view` target, probe ActivityDefinition, and docs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
77
docs/ops-hub-service-catalog.md
Normal file
77
docs/ops-hub-service-catalog.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# Ops Hub Service Catalog Now View
|
||||
|
||||
<!-- generated by ops/render_service_inventory.py; edit ops/service-inventory.yml instead -->
|
||||
|
||||
Source: `ops/service-inventory.yml`
|
||||
Inventory last reviewed: `2026-06-05`
|
||||
|
||||
This is the repo-native first view for `CUST-WP-0047`. It exists so an
|
||||
operator can answer what is running where before the full standalone
|
||||
`ops-hub` application is available.
|
||||
|
||||
## Summary
|
||||
|
||||
| Metric | Count |
|
||||
|---|---:|
|
||||
| Environments | 4 |
|
||||
| Hosts | 3 |
|
||||
| Clusters | 3 |
|
||||
| Services | 8 |
|
||||
| Services: observed_ok | 2 |
|
||||
| Services: unknown | 6 |
|
||||
|
||||
## Service Catalog
|
||||
|
||||
| Service | Where | Owner | Endpoint | Health | Data | Access | Top Gap |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| Gitea (gitea) | CoulombCore<br>type: k3s; cluster: coulombcore-k3s; namespace: default | railiance-apps | https://gitea.coulomb.social/v2/<br>Expected: status 401, OCI registry auth challenge | unknown<br>2026-05-16: Inventory draft records Helm release gitea, namespace default, app version 1.25.4, NodePort 32166, and registry auth challenge. | database:gitea-db<br>pvc:default/gitea-shared-storage | k8s: unknown (coulombcore-k3s/default) | Package token and push/pull verification need current evidence. |
|
||||
| Gitea Database (gitea-database) | CoulombCore<br>type: k3s; cluster: coulombcore-k3s; namespace: databases | railiance-platform | - | unknown<br>2026-05-16: /home/worsch/helix-forge/wiki/OpsHubInventory.md | - | k8s: unknown (coulombcore-k3s/databases) | Backup and restore evidence not recorded in ops inventory. |
|
||||
| Gitea Shared Storage (gitea-shared-storage) | CoulombCore<br>type: k3s; cluster: coulombcore-k3s; namespace: default | railiance-platform<br>railiance-apps | - | unknown<br>2026-05-16: /home/worsch/helix-forge/wiki/OpsHubInventory.md | - | k8s: unknown (coulombcore-k3s/default/pvc/gitea-shared-storage) | Package blob backup and restore evidence not confirmed. |
|
||||
| State Hub (state-hub) | Local Workstation<br>type: local-process; host: local-workstation; ports: 8000 | state-hub<br>the-custodian | http://127.0.0.1:8000/state/health<br>Expected: status 200, health response | observed_ok<br>2026-06-05: State Hub accepted inbox, task, and progress API calls. | postgresql:state-hub | http: observed_ok (http://127.0.0.1:8000) | Future cluster deployment readiness still needs ops evidence. |
|
||||
| Inter-Hub (inter-hub) | ThreePhoenix Production<br>type: external; public_endpoint: https://hub.coulomb.social | inter-hub | https://hub.coulomb.social/api/v2/openapi.json<br>Expected: status 200, OpenAPI document | unknown<br>2026-05-16: /home/worsch/helix-forge/wiki/OpsHubInventory.md | - | https: unknown (https://hub.coulomb.social) | ops-hub bootstrap requires authenticated UI flow or deployment-side migration. |
|
||||
| activity-core (activity-core) | Railiance01<br>type: k3s; cluster: railiance01-k3s; namespace: activity-core | activity-core<br>the-custodian | activity-core API health endpoint<br>Expected: status 200, healthy DB and Temporal status | observed_ok<br>2026-05-23: API health, worker rollout, Temporal CLI schedule listing, and State Hub bridge were verified. | postgresql:activity-core<br>temporal:activity-core<br>nats:railiance01 | k8s: observed_ok (railiance01-k3s/activity-core) | Add explicit ops inventory probes and evidence events. |
|
||||
| Ops Bridge (ops-bridge) | Local Workstation<br>type: bridge; host: local-workstation | ops-bridge | - | unknown<br>2026-05-16: Bridge is useful for connected-server visibility but is not itself the service catalog. | - | ssh-tunnel: unknown (connected remote servers) | Emit reachability evidence into ops-hub instead of relying on bridge state as inventory. |
|
||||
| Haskell Build Agent (haskell-build-agent) | Local Workstation<br>type: systemd; host: haskell-build-vm | the-custodian | http://127.0.0.1:18000<br>Expected: VM can reach State Hub through SSH forward | unknown<br>undated: Build agent is a systemd service and registers with State Hub on boot. | - | ssh: unknown (local workstation reverse tunnel port 12222) | Current tunnel and capability registration need live evidence in ops-hub. |
|
||||
|
||||
## Open Operating Gaps
|
||||
|
||||
### Gitea (`gitea`)
|
||||
|
||||
- Package token and push/pull verification need current evidence.
|
||||
- Backup and restore evidence for database and shared storage not recorded in ops inventory.
|
||||
|
||||
### Gitea Database (`gitea-database`)
|
||||
|
||||
- Backup and restore evidence not recorded in ops inventory.
|
||||
|
||||
### Gitea Shared Storage (`gitea-shared-storage`)
|
||||
|
||||
- Package blob backup and restore evidence not confirmed.
|
||||
|
||||
### State Hub (`state-hub`)
|
||||
|
||||
- Future cluster deployment readiness still needs ops evidence.
|
||||
|
||||
### Inter-Hub (`inter-hub`)
|
||||
|
||||
- ops-hub bootstrap requires authenticated UI flow or deployment-side migration.
|
||||
|
||||
### activity-core (`activity-core`)
|
||||
|
||||
- Add explicit ops inventory probes and evidence events.
|
||||
|
||||
### Ops Bridge (`ops-bridge`)
|
||||
|
||||
- Emit reachability evidence into ops-hub instead of relying on bridge state as inventory.
|
||||
|
||||
### Haskell Build Agent (`haskell-build-agent`)
|
||||
|
||||
- Current tunnel and capability registration need live evidence in ops-hub.
|
||||
|
||||
## Next Evidence Events
|
||||
|
||||
- `ops-service-observed` for each runtime object confirmed by a probe.
|
||||
- `ops-endpoint-verified` for HTTP, HTTPS, tunnel, or cluster endpoints.
|
||||
- `ops-access-path-checked` for non-secret access path checks.
|
||||
- `ops-backup-verified` where backup and restore evidence exists.
|
||||
- `ops-inventory-drift` when observed state differs from this inventory.
|
||||
94
docs/ops-hub-service-inventory.md
Normal file
94
docs/ops-hub-service-inventory.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Ops Hub Service Inventory
|
||||
|
||||
Date: 2026-06-05
|
||||
|
||||
## Purpose
|
||||
|
||||
The first ops-hub "now view" should answer one practical question:
|
||||
|
||||
> What service is running where, who owns it, how is it reached, and what
|
||||
> evidence says it is alive?
|
||||
|
||||
The lowest-effort path is a small read model, not a full new application. The
|
||||
read model starts as `ops/service-inventory.yml`, can be surfaced through
|
||||
Inter-Hub ops widgets, and can later be ingested by the standalone `ops-hub`
|
||||
repo planned in `CUST-WP-0025`.
|
||||
|
||||
## Operating Model
|
||||
|
||||
- Git owns the declared inventory.
|
||||
- Inter-Hub widgets expose the visible ops entities.
|
||||
- Interaction events provide timestamped operational evidence.
|
||||
- activity-core runs repeatable probes and writes evidence.
|
||||
- State Hub continues to own workstreams, tasks, decisions, and progress. It is
|
||||
not the service catalog.
|
||||
|
||||
## Minimal Record Shape
|
||||
|
||||
Each service record should include:
|
||||
|
||||
- `id`: stable lowercase service id, for example `state-hub`.
|
||||
- `name`: human-readable name.
|
||||
- `lifecycle_state`: `observed`, `planned`, `target`, or `retired`.
|
||||
- `health_status`: `unknown`, `observed_ok`, `degraded`, `down`, or `planned`.
|
||||
- `environment`: environment id where the service currently belongs.
|
||||
- `owner_repos`: repos that own desired state, runtime code, or runbooks.
|
||||
- `runtime`: runtime kind and location details, such as `local-process`,
|
||||
`k3s`, `systemd`, `external`, or `bridge`.
|
||||
- `endpoints`: public, local, cluster, or tunnel endpoints with expected
|
||||
non-secret checks.
|
||||
- `backing_stores`: databases, PVCs, object stores, or external stores that
|
||||
must be backed up with the service.
|
||||
- `access_paths`: non-secret descriptions of SSH, Kubernetes, HTTP, or tunnel
|
||||
paths.
|
||||
- `evidence`: links to docs, progress events, probe results, or workplans.
|
||||
- `gaps`: missing evidence or operating controls.
|
||||
|
||||
The schema lives at `schemas/ops-service-inventory.schema.json`.
|
||||
|
||||
## First View
|
||||
|
||||
The initial ops-hub view can be a dense table:
|
||||
|
||||
| Column | Meaning |
|
||||
|---|---|
|
||||
| Service | `name` plus `id` |
|
||||
| Where | environment, host, cluster, namespace |
|
||||
| Owner | owner repo and desired state source |
|
||||
| Endpoint | primary endpoint and expected check |
|
||||
| Health | latest health status and last evidence timestamp |
|
||||
| Data | backing stores and backup gap summary |
|
||||
| Access | access path status |
|
||||
| Gaps | highest-priority missing operating evidence |
|
||||
|
||||
This is enough to make scattered operational reality visible without waiting
|
||||
for a full incident system, runbook executor, or custom database.
|
||||
|
||||
The repo-native version is rendered to `docs/ops-hub-service-catalog.md`:
|
||||
|
||||
```bash
|
||||
make ops-inventory-view
|
||||
```
|
||||
|
||||
## Evidence Events
|
||||
|
||||
Use a small event vocabulary first:
|
||||
|
||||
- `ops-service-observed`: service/runtime object was observed.
|
||||
- `ops-endpoint-verified`: endpoint responded as expected.
|
||||
- `ops-access-path-checked`: access path was checked without storing secrets.
|
||||
- `ops-backup-verified`: backup and restore evidence exists.
|
||||
- `ops-inventory-drift`: observed state differs from declared inventory.
|
||||
|
||||
Event metadata should reference the stable inventory id and include non-secret
|
||||
probe output only.
|
||||
|
||||
## Promotion Path
|
||||
|
||||
1. Keep `ops/service-inventory.yml` as the source artifact.
|
||||
2. Seed or update Inter-Hub widgets from the inventory ids.
|
||||
3. Let activity-core run probes and submit evidence events.
|
||||
4. Build the first ops-hub view from inventory plus latest evidence.
|
||||
5. When the standalone `ops-hub` repo exists, ingest the same inventory and
|
||||
evidence events into the proper Service, AccessPath, Runbook, and Incident
|
||||
models from `CUST-WP-0025`.
|
||||
Reference in New Issue
Block a user