135 lines
3.6 KiB
Markdown
135 lines
3.6 KiB
Markdown
# Live Jibo .NET Test Runbook
|
|
|
|
## Goal
|
|
|
|
Run the first real `Jibo -> .NET OpenJibo cloud` test on the Ubuntu machine using the same working certificate and controlled routing that currently work with the Node server.
|
|
|
|
This runbook intentionally avoids introducing Azure, new hostnames, or new robot bootstrap changes during the first live test.
|
|
|
|
## Recommended Approach
|
|
|
|
Use the existing Ubuntu networking path and certificate material first.
|
|
|
|
- keep the current controlled Wi-Fi / routing arrangement
|
|
- keep the current Jibo-facing hostnames:
|
|
- `api.jibo.com`
|
|
- `api-socket.jibo.com`
|
|
- `neo-hub.jibo.com`
|
|
- keep the Node server available as a fallback
|
|
- run the `.NET` API with the same cert/key material by converting it to a temporary `.pfx` for Kestrel
|
|
|
|
## Prerequisites On Ubuntu
|
|
|
|
Install or confirm these tools:
|
|
|
|
- `dotnet`
|
|
- `openssl`
|
|
- `curl`
|
|
- `python3`
|
|
|
|
Optional but useful:
|
|
|
|
- `pwsh`
|
|
|
|
`pwsh` is not required anymore for the Ubuntu live test path if you use the bash/python helpers added here.
|
|
|
|
## Certificate Plan
|
|
|
|
The Node server currently uses:
|
|
|
|
- `cert.pem`
|
|
- `key.pem`
|
|
|
|
The `.NET` API can reuse that same material for the test by converting it at startup into a temporary `.pfx`.
|
|
|
|
If your current cert file already includes the working chain, use it as-is.
|
|
|
|
If your chain is separate, pass it as `CHAIN_PEM`.
|
|
|
|
## Step By Step
|
|
|
|
1. On Ubuntu, stop the Node server if it is currently bound to port `443`.
|
|
|
|
2. From the repo root, start the `.NET` cloud using the same cert/key:
|
|
|
|
```bash
|
|
./scripts/cloud/start-dotnet-with-node-cert.sh
|
|
```
|
|
|
|
Optional environment overrides:
|
|
|
|
```bash
|
|
CERT_PEM=/path/to/cert.pem \
|
|
KEY_PEM=/path/to/key.pem \
|
|
CHAIN_PEM=/path/to/chain.pem \
|
|
ASPNETCORE_URLS="https://0.0.0.0:443;http://0.0.0.0:24605" \
|
|
./scripts/cloud/start-dotnet-with-node-cert.sh
|
|
```
|
|
|
|
3. In another terminal, run the prep checklist:
|
|
|
|
```bash
|
|
./scripts/cloud/invoke-live-jibo-prep.sh
|
|
```
|
|
|
|
4. Verify controlled routing from the Ubuntu environment:
|
|
|
|
```bash
|
|
./scripts/bootstrap/test-openjibo-routing.sh
|
|
```
|
|
|
|
5. Power on Jibo and let it connect using the existing controlled network configuration.
|
|
|
|
6. Perform the first live checks in this order:
|
|
|
|
- startup / bootstrap reachability
|
|
- one simple chat turn
|
|
- one joke turn
|
|
|
|
7. After the run, summarize the captured websocket telemetry:
|
|
|
|
```bash
|
|
./scripts/cloud/get-websocket-capture-summary.sh
|
|
```
|
|
|
|
8. Inspect exported fixtures under:
|
|
|
|
- `captures/websocket/fixtures/`
|
|
|
|
9. Import the best fixture into the checked-in websocket fixture set:
|
|
|
|
```bash
|
|
python3 ./scripts/cloud/import-websocket-capture-fixture.py \
|
|
/path/to/exported.flow.json \
|
|
neo-hub-real-jibo-first-chat
|
|
```
|
|
|
|
10. Keep notes on:
|
|
|
|
- whether startup succeeded cleanly
|
|
- which websocket paths connected
|
|
- whether audio stayed pending or finalized
|
|
- whether EOS timing matched expectations
|
|
- whether any unexpected message families appeared
|
|
|
|
## What To Do If The Test Fails
|
|
|
|
If the robot does not connect or the first turn fails:
|
|
|
|
1. confirm the `.NET` API is actually bound on `443`
|
|
2. confirm the cert presented by the `.NET` API matches the currently working Node cert path
|
|
3. confirm the Ubuntu routing still points Jibo traffic at the same machine
|
|
4. compare the `.NET` websocket capture output with prior Node logs
|
|
5. temporarily switch back to Node to confirm the environment still works
|
|
|
|
## Not In Scope For This First Test
|
|
|
|
Do not mix these into the first live run:
|
|
|
|
- Azure deployment cutover
|
|
- new permanent OpenJibo hostnames
|
|
- IaC rollout
|
|
- new device bootstrap edits beyond the already working setup
|
|
|
|
Those are valid next steps, but they should follow the first successful `.NET` live capture, not precede it.
|