# inter-hub on railiance01

Interaction Hub deployment for **`https://hub.coulomb.social`**.

Companion source repo: `coulomb/inter-hub`. This repo owns the Railiance app
Helm surface and operator targets, not the runtime application code.

## Hosts and release surface

| Server | IP | Role |
|---|---|---|
| Railiance01 | `92.205.62.239` | Production k3s; deploy S5 apps here |
| CoulombCore | `92.205.130.254` | Bootstrap / prerelease only |

| Item | Value |
|---|---|
| Namespace | `inter-hub` |
| Helm release | `inter-hub` |
| Chart | `charts/inter-hub` |
| Values | `helm/inter-hub-values.yaml` |
| Image | `gitea.coulomb.social/coulomb/inter-hub:<tag>` |
| Secret | `inter-hub-env` |
| Production kubeconfig | `~/.kube/config-hosteurope` |

## Current evidence

Read-only checks on 2026-06-15 showed:

- Helm release `inter-hub` revision 2 is deployed in namespace `inter-hub`.
- `helm get values` reports `image.tag: 11ff61c`,
  `image.pullPolicy: Always`, and `runMigrations: false`.
- The live Deployment image is
  `92.205.130.254:32166/coulomb/inter-hub:790b5e5`, so production image state
  has drifted from Helm values and from this repo's desired Gitea registry
  target.
- The pod is Running and `certificate/inter-hub-tls` is Ready on Railiance01.
- `GET https://hub.coulomb.social/api/v2/hubs` returned `200` unauthenticated,
  proving the route is present but not satisfying the expected `401` auth gate.
- `/openapi.json`, `/api/openapi.json`, `/swagger.json`, and
  `/api/swagger.json` returned `404`; the public OpenAPI route still needs to
  be confirmed by the upstream inter-hub owner.

## Deploy

Use the Railiance01 kubeconfig. The Makefile defaults to
`~/.kube/config-hosteurope` and fails fast when it is missing.

```bash
make inter-hub-dry-run
INTER_HUB_IMAGE_TAG=91037a4 make inter-hub-deploy
make inter-hub-status
```

Deploy automation should pass the image tag without rewriting
`helm/inter-hub-values.yaml`. The production deploy target requires this
explicit tag:

```bash
INTER_HUB_IMAGE_TAG=91037a4 make inter-hub-deploy
```

Use a tag at or after the commit that contains the required v2 bootstrap API
routes. The upstream inter-hub workplan names `91037a4` as the first expected
tag for the IHUB-WP-0019 route surface; verify the actual registry tag before
announcing rollout.

## Release verification

```bash
make inter-hub-release-info
```

This wraps the required non-secret inspection commands:

```bash
helm history inter-hub -n inter-hub
helm get values inter-hub -n inter-hub
kubectl describe deploy/inter-hub -n inter-hub
kubectl get pods -n inter-hub -o wide
```

Confirm the rendered deployment uses the intended immutable image tag and does
not rely on a stale `latest` image.

The chart intentionally keeps the legacy Deployment and Service selector
`app=inter-hub` because the live Helm release was created with that selector.
Kubernetes treats Deployment selectors as immutable; do not change this
selector during a normal in-place production upgrade.

## Migration boundary

The Railiance app chart currently does **not** run inter-hub database
migrations. Treat migration execution as an upstream inter-hub operator step
and record the evidence before closing a production rollout. Do not describe
migrations as automatic unless the chart grows an explicit init job/container
or another committed migration mechanism.

## Smoke checks

After rollout, the unauthenticated v2 API gate should be present:

```bash
make inter-hub-smoke
```

Expected results:

- `GET https://hub.coulomb.social/api/v2/hubs` returns `401`, not `404`.
- OpenAPI lists `/hubs`, `/hub-capability-manifests`, `/api-consumers`, and
  `/policy-scopes`.