generated from coulomb/repo-seed
ops-hub-bootstrap
This commit is contained in:
@@ -29,7 +29,15 @@ VSM classification is stored in the manifest capability description for now:
|
||||
- `vsm_function`: `OPS`
|
||||
- `vsm_system`: `S1`
|
||||
|
||||
Inter-Hub does not yet have first-class hub metadata columns for these values.
|
||||
Newer Inter-Hub schemas have first-class hub metadata columns for these values.
|
||||
The SQL fallback sets those columns when present and still carries the same
|
||||
classification in the manifest description for older deployments.
|
||||
|
||||
As of the 2026-05-19 access check, the workstation kubeconfig only points at
|
||||
CoulombCore (`92.205.130.254`) and does not include the Railiance01
|
||||
(`92.205.62.239`) cluster where `hub.coulomb.social` resolves. SSH key access
|
||||
to `root`, `worsch`, and `ubuntu` on Railiance01 was denied, so the SQL fallback
|
||||
must be run from a host/session that already has Railiance01 cluster access.
|
||||
|
||||
## UI Path
|
||||
|
||||
@@ -61,6 +69,31 @@ Inter-Hub does not yet have first-class hub metadata columns for these values.
|
||||
11. Seed the widgets from `wiki/ops-hub-widgets.seed.json` through the UI or
|
||||
migration fallback.
|
||||
|
||||
## SQL Fallback Path
|
||||
|
||||
From a shell with Railiance01 Kubernetes access, run:
|
||||
|
||||
```bash
|
||||
kubectl exec -i -n databases net-kingdom-pg-1 -- \
|
||||
psql -U postgres -d interhub \
|
||||
< /home/worsch/helix-forge/wiki/ops-hub-bootstrap.sql
|
||||
```
|
||||
|
||||
If using the HostEurope kubeconfig from the workstation, first restore
|
||||
`~/.kube/config-hosteurope` as documented by `railiance-cluster`, then run:
|
||||
|
||||
```bash
|
||||
KUBECONFIG=~/.kube/config-hosteurope \
|
||||
kubectl exec -i -n databases net-kingdom-pg-1 -- \
|
||||
psql -U postgres -d interhub \
|
||||
< /home/worsch/helix-forge/wiki/ops-hub-bootstrap.sql
|
||||
```
|
||||
|
||||
The SQL fallback creates the hub, active manifest, registry entries, API
|
||||
consumer row, and seed widgets. It does not create the one-time visible static
|
||||
API key; generate that in the authenticated Inter-Hub UI and store it outside
|
||||
Git.
|
||||
|
||||
## Validation
|
||||
|
||||
After manifest activation:
|
||||
|
||||
@@ -23,6 +23,25 @@ SET name = EXCLUDED.name,
|
||||
domain = EXCLUDED.domain,
|
||||
hub_kind = EXCLUDED.hub_kind;
|
||||
|
||||
-- Newer inter-hub schemas have first-class VSM metadata columns. Keep this
|
||||
-- block conditional so the bootstrap still works against an older deployment
|
||||
-- where the metadata is only carried by the manifest description.
|
||||
DO $$
|
||||
BEGIN
|
||||
IF EXISTS (
|
||||
SELECT 1
|
||||
FROM information_schema.columns
|
||||
WHERE table_name = 'hubs'
|
||||
AND column_name = 'hub_family'
|
||||
) THEN
|
||||
UPDATE hubs
|
||||
SET hub_family = 'vsm',
|
||||
vsm_function = 'OPS',
|
||||
vsm_system = '1'
|
||||
WHERE slug = 'ops-hub';
|
||||
END IF;
|
||||
END $$;
|
||||
|
||||
WITH hub AS (
|
||||
SELECT id FROM hubs WHERE slug = 'ops-hub'
|
||||
)
|
||||
|
||||
@@ -152,10 +152,10 @@ Decision:
|
||||
possible, with a migration-backed fallback when a repeatable bootstrap is
|
||||
needed before the public API is hardened.
|
||||
- Treat Pattern A, API Consumer Hub, as the first implementation pattern.
|
||||
- Store VSM classification in the manifest capability description for now,
|
||||
because the current `hubs` table only has `slug`, `name`, `domain`, and
|
||||
`hub_kind`; there are no first-class `hub_family`, `vsm_function`, or
|
||||
`vsm_system` columns yet.
|
||||
- Store VSM classification in first-class hub metadata where the target
|
||||
Inter-Hub schema has `hub_family`, `vsm_function`, and `vsm_system`; keep the
|
||||
same values in the manifest capability description for compatibility with
|
||||
older deployments and API consumers.
|
||||
- Use `hub_kind = domain` for `ops-hub`.
|
||||
- Record missing first-class VSM metadata fields and create endpoints as
|
||||
Inter-Hub hardening work under T10.
|
||||
@@ -690,6 +690,38 @@ This workplan is complete when:
|
||||
9. The bootstrap path is reusable enough that `syn-hub` can be created next
|
||||
without rediscovering the whole process.
|
||||
|
||||
## Implementation Log
|
||||
|
||||
### 2026-05-19 — Live bootstrap access check
|
||||
|
||||
Attempted to execute the prepared bootstrap path.
|
||||
|
||||
Findings:
|
||||
|
||||
- `hub.coulomb.social` resolves to Railiance01 (`92.205.62.239`).
|
||||
- The current workstation kubeconfig has only the `default` context and points
|
||||
at CoulombCore (`92.205.130.254`).
|
||||
- `~/.kube/config-hosteurope` is missing, so the documented Railiance01
|
||||
kubeconfig path is not available locally.
|
||||
- `kubectl` against the current context has no `inter-hub` deployment because
|
||||
it is the CoulombCore cluster.
|
||||
- SSH key auth to `root@92.205.62.239`, `worsch@92.205.62.239`, and
|
||||
`ubuntu@92.205.62.239` was denied.
|
||||
|
||||
Result:
|
||||
|
||||
- Live `ops-hub` bootstrap was not applied from this session.
|
||||
- `wiki/ops-hub-bootstrap.sql` was strengthened to set first-class VSM hub
|
||||
metadata when the target Inter-Hub schema supports it.
|
||||
- `wiki/OpsHubBootstrapRunbook.md` now records the exact SQL fallback command
|
||||
to run from a Railiance01-capable session.
|
||||
|
||||
Next required operator action:
|
||||
|
||||
- Restore/provide Railiance01 Kubernetes access, or run
|
||||
`wiki/ops-hub-bootstrap.sql` from a host that already has access to the
|
||||
`net-kingdom-pg-1` pod in the `databases` namespace.
|
||||
|
||||
## Notes
|
||||
|
||||
`ops-hub` should complement State Hub during the transition:
|
||||
|
||||
Reference in New Issue
Block a user