Skip to content

ci: auto-update release notes on push to main - #1

Closed
ericksoa wants to merge 1 commit into
mainfrom
ci/auto-release-notes
Closed

ericksoa wants to merge 1 commit into
mainfrom
ci/auto-release-notes

Conversation

@ericksoa

Copy link
Copy Markdown
Member

Migrated from NVIDIA/openshell-openclaw-plugin#31

Summary

  • Adds a GitHub Actions workflow that auto-updates docs/about/release-notes.md on every push to main
  • Categorizes commits into Features / Fixes / Other based on commit message prefixes (case-insensitive)
  • Filters out noise: reverts, chores, docs-only, test-only, style, and low-signal commits
  • Scopes to only new commits since last run (uses [release-notes] marker in commit message)
  • Self-loop prevention: skips if the triggering commit is from this workflow
  • Commits back with -s (DCO signed-off)

How it works

  1. On push to main, collects non-merge commits since last tag or last [release-notes] commit
  2. Categorizes by prefix: add/feat → Features, fix → Fixes, everything else → Other
  3. Inserts a dated block under the ## 0.1.0 Unreleased heading
  4. Commits and pushes the updated file

Test plan

  • Merge a commit to main and verify the workflow runs
  • Check that docs/about/release-notes.md gets a new dated section
  • Verify the workflow doesn't trigger itself (no infinite loop)
  • Verify commit messages are correctly categorized

…to main

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
ericksoa pushed a commit that referenced this pull request Mar 17, 2026
Add a preflight check that catches the #1 onboarding blocker on
Ubuntu 24.04, DGX Spark, and WSL2. When cgroup v2 is active but
Docker's daemon.json lacks "default-cgroupns-mode": "host",
onboarding now fails fast with a clear error and fix instructions
instead of failing late at gateway startup with a cryptic kubelet
error.

Closes #16
@wscurran wscurran added the CI/CD label Mar 20, 2026
@wscurran

Copy link
Copy Markdown
Contributor

Thanks for setting up a GitHub Actions workflow that automatically updates the release notes on pushes to the main branch, which could help keep the documentation up to date and reduce manual effort.

@cv

cv commented Mar 21, 2026

Copy link
Copy Markdown
Collaborator

Hi @ericksoa! Thanks for putting this together — auto-updating release notes is something we've been wanting. Since this was opened, the repo has seen a lot of activity: we've added CI checks, new features, and restructured a few things. Would you mind rebasing onto the latest main when you get a chance? That way we can give it a proper review with everything up to date. Appreciate it!

@ericksoa

Copy link
Copy Markdown
Member Author

Superseded — release notes page now points to GitHub native releases/commits/PRs.

@ericksoa ericksoa closed this Mar 22, 2026
jessesanford pushed a commit to jessesanford/NemoClaw that referenced this pull request Mar 24, 2026
- Default model: nvidia/nemotron-3-super-120b-a12b (March 2026 release,
  12B active / 120B total MoE, 5x throughput)
- Replace meta/llama-3.3-70b-instruct with Nemotron 3 Super in the
  nvidia provider catalog (Dockerfile sed patch at build time)
- All NVIDIA models in provider: Nemotron 70B, Mistral NeMo Minitron,
  Nemotron 3 Super — no Meta/Llama
- Blueprint default profile updated to nemotron-3-super-120b-a12b
- Tracked as tech debt: NVIDIA#1

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jessesanford pushed a commit to jessesanford/NemoClaw that referenced this pull request Mar 24, 2026
…IA#62)

Add a preflight check that catches the NVIDIA#1 onboarding blocker on
Ubuntu 24.04, DGX Spark, and WSL2. When cgroup v2 is active but
Docker's daemon.json lacks "default-cgroupns-mode": "host",
onboarding now fails fast with a clear error and fix instructions
instead of failing late at gateway startup with a cryptic kubelet
error.

Closes NVIDIA#16
realkim93 added a commit to realkim93/NemoClaw that referenced this pull request Apr 1, 2026
…docs

Add two behavioral tests that directly validate cv's blocker NVIDIA#1 fix:
- Healthy gateway is preserved (no destroy/forward-stop) on rerun
- Stale vs healthy vs active-unnamed states trigger correct cleanup

Also add setup-jetson entry to docs/reference/commands.md.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ericksoa pushed a commit that referenced this pull request Apr 7, 2026
… (#1305)

## Summary

Fixes the four issues reported in #1114 — EACCES permission errors and
missing gateway token when running inside the NemoClaw sandbox.

### Issue mapping

| # | Reported error | Fix |
|---|----------------|-----|
| 1 | `EACCES: open '/sandbox/.openclaw/openclaw.json.*.tmp'` |
`install_configure_guard` — intercepts `openclaw configure` with a clear
error and directs users to `nemoclaw onboard --resume` on the host |
| 2 | Same as #1 (different PID) | Same fix |
| 3 | `EACCES: mkdir '/sandbox/.openclaw/credentials'` | Already
resolved on main via #1519 (credentials symlink to `.openclaw-data/`) |
| 4 | No WhatsApp QR code | Consequence of #3, also resolved by #1519 |

### Root cause (issues 1 & 2)

OpenClaw's `configure` command performs atomic writes — it creates a
temp
file (`openclaw.json.PID.UUID.tmp`) in the same directory as the config.
Since `/sandbox/.openclaw/` is Landlock read-only at the kernel level,
file creation is rejected with EACCES. This is by design: the sandbox
config is intentionally immutable at runtime.

Rather than weakening Landlock (security regression), we intercept the
command in the sandbox shell and guide users to the correct host-side
workflow.

### Changes

**1. `install_configure_guard()`** — Writes a shell function wrapper to
`.bashrc`/`.profile` that intercepts `openclaw configure` and prints:
```
Error: 'openclaw configure' cannot modify config inside the sandbox.
The sandbox config is read-only (Landlock enforced) for security.

To change your configuration, exit the sandbox and run:
  nemoclaw onboard --resume

This rebuilds the sandbox with your updated settings.
```
All other `openclaw` subcommands pass through to the real binary.

**2. `export_gateway_token()`** — Reads `gateway.auth.token` from
`openclaw.json` and exports it as `OPENCLAW_GATEWAY_TOKEN`, so
interactive sessions (`openshell sandbox connect`) can authenticate
with the gateway. Persists to `.bashrc`/`.profile` using idempotent
marker blocks and cleans stale tokens on revocation.

**3. `_read_gateway_token()` helper** — Shared Python snippet used by
both `export_gateway_token` and `print_dashboard_urls` (deduplication,
uses `with open()` context manager).

All three are called in both root and non-root startup paths.

## Security properties preserved

- `/sandbox/.openclaw` remains root-owned, Landlock read-only
- `openclaw.json` remains chmod 444 (immutable)
- No new attack surface — token is read-only from existing config
- `command openclaw` bypass preserves all non-configure functionality

Fixes #1114

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
gemini2026 pushed a commit to gemini2026/NemoClaw that referenced this pull request Apr 14, 2026
…IA#1114) (NVIDIA#1305)

## Summary

Fixes the four issues reported in NVIDIA#1114 — EACCES permission errors and
missing gateway token when running inside the NemoClaw sandbox.

### Issue mapping

| # | Reported error | Fix |
|---|----------------|-----|
| 1 | `EACCES: open '/sandbox/.openclaw/openclaw.json.*.tmp'` |
`install_configure_guard` — intercepts `openclaw configure` with a clear
error and directs users to `nemoclaw onboard --resume` on the host |
| 2 | Same as NVIDIA#1 (different PID) | Same fix |
| 3 | `EACCES: mkdir '/sandbox/.openclaw/credentials'` | Already
resolved on main via NVIDIA#1519 (credentials symlink to `.openclaw-data/`) |
| 4 | No WhatsApp QR code | Consequence of NVIDIA#3, also resolved by NVIDIA#1519 |

### Root cause (issues 1 & 2)

OpenClaw's `configure` command performs atomic writes — it creates a
temp
file (`openclaw.json.PID.UUID.tmp`) in the same directory as the config.
Since `/sandbox/.openclaw/` is Landlock read-only at the kernel level,
file creation is rejected with EACCES. This is by design: the sandbox
config is intentionally immutable at runtime.

Rather than weakening Landlock (security regression), we intercept the
command in the sandbox shell and guide users to the correct host-side
workflow.

### Changes

**1. `install_configure_guard()`** — Writes a shell function wrapper to
`.bashrc`/`.profile` that intercepts `openclaw configure` and prints:
```
Error: 'openclaw configure' cannot modify config inside the sandbox.
The sandbox config is read-only (Landlock enforced) for security.

To change your configuration, exit the sandbox and run:
  nemoclaw onboard --resume

This rebuilds the sandbox with your updated settings.
```
All other `openclaw` subcommands pass through to the real binary.

**2. `export_gateway_token()`** — Reads `gateway.auth.token` from
`openclaw.json` and exports it as `OPENCLAW_GATEWAY_TOKEN`, so
interactive sessions (`openshell sandbox connect`) can authenticate
with the gateway. Persists to `.bashrc`/`.profile` using idempotent
marker blocks and cleans stale tokens on revocation.

**3. `_read_gateway_token()` helper** — Shared Python snippet used by
both `export_gateway_token` and `print_dashboard_urls` (deduplication,
uses `with open()` context manager).

All three are called in both root and non-root startup paths.

## Security properties preserved

- `/sandbox/.openclaw` remains root-owned, Landlock read-only
- `openclaw.json` remains chmod 444 (immutable)
- No new attack surface — token is read-only from existing config
- `command openclaw` bypass preserves all non-configure functionality

Fixes NVIDIA#1114

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
prekshivyas added a commit to ColinM-sys/NemoClaw that referenced this pull request Apr 16, 2026
…xercised

CodeRabbit correctly flagged that the original test swapped the lock
file on stat NVIDIA#1 which caused isProcessAlive to see a live PID and
exit early — unlinkIfInodeMatches was never called. Move the swap to
after stat NVIDIA#1 returns so the stale-cleanup branch is actually reached
and the inode comparison is tested.

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
prekshivyas added a commit to ColinM-sys/NemoClaw that referenced this pull request Apr 16, 2026
…exercised

CodeRabbit correctly flagged that swapping on stat NVIDIA#1 caused
readFileSync to see the live PID and exit via isProcessAlive —
unlinkIfInodeMatches was never called. Move the swap to just before
stat NVIDIA#2 (inside unlinkIfInodeMatches): stat NVIDIA#1 reads the original
stale inode, readFileSync sees the dead PID, isProcessAlive returns
false, stale-cleanup runs, and stat NVIDIA#2 sees the new inode and skips
the unlink.

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
prekshivyas added a commit to ColinM-sys/NemoClaw that referenced this pull request Apr 16, 2026
…exercised

CodeRabbit correctly flagged that swapping on stat NVIDIA#1 caused
readFileSync to see the live PID and exit via isProcessAlive —
unlinkIfInodeMatches was never called. Move the swap to just before
stat NVIDIA#2 (inside unlinkIfInodeMatches): stat NVIDIA#1 reads the original
stale inode, readFileSync sees the dead PID, isProcessAlive returns
false, stale-cleanup runs, and stat NVIDIA#2 sees the new inode and skips
the unlink.

Use write-to-temp + rename instead of unlink + recreate to guarantee
a different inode even on tmpfs/overlayfs which can reuse inodes.

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
jyaunches pushed a commit that referenced this pull request Apr 20, 2026
- Remove unused getForwardList() call from getActiveSandboxSessions —
  only pgrep/ps is needed for SSH session detection (warning #1)
- Consolidate double-prompt in sandboxDestroy into single enriched
  confirmation prompt (warning #2)
- Remove noisy cleanupGatewayAfterLastSandbox forward check that would
  always fire due to dashboard forward (warning #3)
- Use word-boundary regex in parseSshProcesses to prevent false positives
  when sandbox names share prefixes (warning #4)
- Export SessionClassification as named interface (suggestion #1)
- Use cross-platform ps -axo instead of Linux-only pgrep -a for macOS
  compatibility (suggestion #2)
- Add forwardCount to SessionClassification for future consumers
- Add tests for word-boundary matching edge cases
tantodefi referenced this pull request in tantodefi/supachad Jul 3, 2026
…, notif bell

Driven by reading the actual runs (bug-report / experiments / skill-improve):
- FIX the empty-response failure bug-report kept catching: cheap-tier reasoning was
  ON with a 2048 cap, so "detailed thinking on" ate the whole budget and returned an
  empty answer (finishReason=length, textLength=0 -> INVALID_OUTPUT). agents.js now
  defaults cheap reasoning OFF and gives reasoning runs token headroom (8192 cheap /
  32768 capable, clamped). The nightly loop now produces real output.
- Widen the arena (toward 10x useful trials): 14 seed candidates (6 prompts, 6
  models, 2 params); POLICY targetActive 6->10, maxActive 10->16, expandPerRun 1->4,
  championTopK 2->3 (more champions feed the fusion panel).
- Close the value loop: experiments exports the top drafter-prompt champion to
  state/champion-prompt.json so prod can adopt the winning prompt (skill-improve's #1
  proposal) instead of leaving it stranded in the leaderboard.
- Schedule more (the timers/crons ask): experiments now runs 3x/day (benchmarks each
  run; the reporting loop fires once at 05:00 to avoid approval spam). New launchd
  timers via run-workflow.sh + install-schedules.sh: log-digest (6h), mcp-health (1h),
  fail-only-report (1h). self-improve added to the nightly.
- Notifications: always-visible header bell to enable/test browser approval push, so
  the channel isn't buried in the launch drawer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cv pushed a commit that referenced this pull request Jul 6, 2026
…board dcode identity failure (#6343)

## Summary
Fixes two E2E-harness problems surfaced by the E2E dispatch on `main`:

1. **e2e-live source require hook** — the `hermes-inference-switch` live
suite (added in #6335) failed at collection with `Cannot find module
'../runner'` because the `e2e-live` Vitest project never loaded the
typed-source require hook.
2. **cloud-onboard observability** — the cloud-experimental check-04
(added in #6332) fails on `main` with `could not read initial dcode
identity`, but the real `dcode identity` error is captured into a shell
var and discarded, so it can't be diagnosed.

## Changes
- `vitest.config.ts`: add `setupFiles:
["test/helpers/onboard-script-mocks.cjs"]` to the `e2e-live` project
(mirrors `cli`). Registers the typed-source `.ts` require hook
**in-process** — deliberately not via `env.NODE_OPTIONS`, so `--require`
never leaks into the real CLI subprocesses live tests spawn.
-
`test/e2e/e2e-cloud-experimental/checks/04-deepagents-code-fresh-reonboard.sh`:
on both `dcode identity` reads, print the captured stdout+stderr to
stdout (so it lands in `result.json`) before `fail`. No change to
pass/fail logic — only makes the existing failure observable.

### Root cause — #1 (fixed here)
`hermes-inference-switch` is the first `e2e-live` suite to import a deep
`src` graph — its helpers import `src/lib/inference/config.ts`, which
transitively loads `ollama-runtime-context.ts`'s runtime
`require("../runner")`. Without the require hook, Node's native CJS
resolver can't resolve the extensionless `.ts` → suite throws at
collection (`0 tests`, ~37s). Only this suite hit it; others drive the
CLI as a subprocess and import only fixtures. `runner.ts` has no
circular dependency on the inference graph, so the in-process hook
resolves it fully.

### Root cause — #2 (observability only; product root cause pending)
`cloud-onboard` was green on `main` through 2026-07-06 00:56 UTC and
failed on the first main E2E after #6332 landed (19:50 UTC) — #6332
added check-04, which has never passed on main. `dcode identity` is the
NemoClaw wrapper (`agents/langchain-deepagents-code/dcode-wrapper.sh`);
its identity path returns 0 in isolation and #6332 did not modify it, so
the non-zero exit is a runtime condition in #6332's new "recreate/verify
live identity" onboarding flow. That can't be pinned without the
swallowed stderr — which this change surfaces. Product root cause is for
the #6332 author to fix once the next run shows the real error.

## Type of Change
- [x] Code change (feature, bug fix, or refactor)

## Quality Gates
- [x] Existing tests cover changed behavior — justification: both
changes are E2E-harness config/diagnostics. #1: the `e2e-live` suites
exercise the hook — verified the previously-failing
`hermes-inference-switch` suite now collects and all `e2e-live` suites
report 0 collection errors, and the full `e2e-all` dispatch ran the
switch job (hosted) green. #2: pure diagnostic output; no pass/fail
change.
- [x] Docs not applicable — justification: internal test-harness
config/diagnostics; no user-facing behavior.
- [x] Sensitive paths changed (onboarding/inference/runner adjacent via
test config)
- [x] Sensitive-path review completed or maintainer-approved waiver
recorded — justification: changes are confined to Vitest test-runner
setup (`vitest.config.ts`) and an E2E diagnostic print; no product
runtime code path is altered. The require hook is in-process only and
does not touch product CLI subprocesses.

## Verification
- [x] PR description includes the DCO sign-off declaration and every
commit appears as `Verified` in GitHub
- [x] Normal `pre-commit`, `commit-msg`, and `pre-push` hooks passed —
note: `pre-push` `tsc-cli` skipped for a pre-existing local-only
`noImplicitAny` false-positive in
`test/helpers/mcp-lifecycle-lock-properties.ts` and
`src/lib/state/mcp-lifecycle-lock-identity.test.ts` (unrelated to this
diff); CI `tsc-cli` covers it. Check-04 passed `bash -n` and the
`shellcheck`/`shfmt` pre-commit hooks.
- [x] Targeted behavior tests pass — command/result:
`NEMOCLAW_RUN_LIVE_E2E=1 npx vitest list --project e2e-live` → switch
suite collects; whole project 0 collection errors (before the fix it
reproduced `Cannot find module '../runner'`). Full `e2e-all` dispatch on
this branch ran `hermes-inference-switch (hosted)` green.
- [x] No secrets, API keys, or credentials committed

---
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Improved reliability of live end-to-end test runs by loading the
required hook inside the test process, avoiding leakage into real CLI
subprocesses.
* Made identity checks in sandboxed cloud experimental flows more
robust, with clearer diagnostics when identity lookup fails.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
zeekay pushed a commit to Dream-AI-4444/NemoClaw that referenced this pull request Sep 9, 2026
- Default model: nvidia/nemotron-3-super-120b-a12b (March 2026 release,
  12B active / 120B total MoE, 5x throughput)
- Replace meta/llama-3.3-70b-instruct with Nemotron 3 Super in the
  nvidia provider catalog (Dockerfile sed patch at build time)
- All NVIDIA models in provider: Nemotron 70B, Mistral NeMo Minitron,
  Nemotron 3 Super — no Meta/Llama
- Blueprint default profile updated to nemotron-3-super-120b-a12b
- Tracked as tech debt: NVIDIA#1

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
zeekay pushed a commit to Dream-AI-4444/NemoClaw that referenced this pull request Sep 9, 2026
…IA#62)

Add a preflight check that catches the NVIDIA#1 onboarding blocker on
Ubuntu 24.04, DGX Spark, and WSL2. When cgroup v2 is active but
Docker's daemon.json lacks "default-cgroupns-mode": "host",
onboarding now fails fast with a clear error and fix instructions
instead of failing late at gateway startup with a cryptic kubelet
error.

Closes NVIDIA#16
cv added a commit that referenced this pull request Nov 4, 2026
…4192)

## Failure

The GPU autoscaling example has no way to load the chart's GPUs through
the agents, which is what makes its autoscaler scale.
#14009 had load clients, but they sent each prompt with `kubectl exec`
into the sandbox pods, around the gateway's authentication, and read pod
names and runtime IDs from NemoClaw's `terraform.tfstate`.
With the `development` profile that example uses, nobody but NemoClaw
can authenticate to the gateway, so no supported client could reach the
agents.

## Decision

Follows #14191 (merged), on which this was stacked.

- `examples/kubernetes/gpu-autoscaling/load.sh`, a Bash script with the
OpenShell CLI, `curl` and `jq`. It reads `nemoclaw apply -o json` and
sends `PROMPTS` prompts across the agents, at most `CONCURRENCY` at a
time through `xargs -P`, then prints how many it sent and how many
replied, the median, 95th-percentile and longest latency overall and per
sandbox, up to 10 failures, and one reply per sandbox. It exits nonzero
if any request failed. Each sandbox takes one of the two paths that need
no state files or `kubectl exec`:
- **Hermes's API server**, when apply lists an `api` interface and an
`api` service URL for the sandbox: OpenAI chat completions to
`serviceUrls.SANDBOX.api`, through the gateway's port forward and with
its client certificate. The script reads the interface token once, with
`openshell sandbox exec … cat` and the reported `tokenPath`, into a
private temporary file.
- **`fabric-agent-ctl invoke`** for any other sandbox, such as OpenClaw
or Deep Agents, through `openshell sandbox exec` with
`agents.SANDBOX.runtimeId` (#14186).
- `two-runtimes.yaml`: a Hermes sandbox on the chart's vLLM release and
an OpenClaw sandbox on its Ollama release, the two that
`install-two-runtimes.sh` installs (#14191). It uses the `oidc` profile,
and declares Hermes's `api` interface with a `serviceExposures` entry
using `BEARER_PASSTHROUGH`, because OpenShell's default `STRIP` drops
the token Hermes checks. Its Envoy Service names are the ones Envoy
Gateway v1.8.3 created for those Gateways on kind; it shortens a
Gateway's name to 48 characters before the hash.
- `README.md`: **Drive Load Through the Agents**, with the apply and run
commands, the variables, and the limits: the gateway's one CPU for
`sandbox exec`, Fabric's one invocation at a time per runtime, Hermes's
10 concurrent runs per sandbox, what a service URL skips, and that the
CLI doesn't renew a client-credentials token (NVIDIA/OpenShell#4287).

From #14009's `e2e-fabric-load-test.py` and client scripts, this keeps
the prompts, the per-request timeout, the success check on
`result.status` and `result.output.response`, and per-sandbox counts. It
leaves out the HPA polling and the stop-at-ceiling logic, which belong
to the chart and `kubectl get hpa --watch`; the OpenClaw tool pinning,
which edited Fabric's generated configuration inside the sandbox; and
the timeline and CSV output.

## Validation

- `cargo ci` on `c6a581a9cf`: all selected steps passed in 135 s; test
ran 1,827 tests and lifecycle 101. `cargo test -p nemoclaw-onboarding
two_runtimes` ran the new file's onboarding journey.
- `shellcheck` 0.11 (`koalaman/shellcheck:stable`) on `load.sh`: no
findings.
- Live run on a local kind cluster (kind v0.33.0,
`kindest/node:v1.37.0`, Agent Sandbox 1.0.3, linux/arm64, no GPU), with
resources I created and removed afterwards:
- **Model:** the chart from nemoclaw-community `cb46db83ab` installed
with `helm`, with Ollama and `qwen3:0.6b` on CPU, no GPU request or node
selector, no ServiceMonitor or HPA, arm64 digests for Ollama 0.40.11 and
`node:22-bookworm-slim`, behind Envoy Gateway v1.8.3. Both sandboxes
used its one Envoy Service, with `model: qwen3:0.6b`.
- **Issuer:** Keycloak 26.4 in the cluster, at `https://<kind node
IP>:30443/realms/openshell` with a test CA, so that the gateway pod and
the host see the same issuer URL, with a confidential client whose
service account has the admin role in a `roles` claim and audience
`openshell`. The kind HCL cases' issuer serves only discovery and keys,
with no token endpoint, so the OpenShell CLI can't sign in through it.
- **Deployment:** `two-runtimes.yaml` with the context, issuer,
endpoints, model and image digests replaced, and `openclaw` and `hermes`
built for linux/arm64 and pushed to a registry on the kind network.
`nemoclaw apply -o json` with the bundle from this branch succeeded, and
reported `serviceUrls.user-0000.api` as
`https://nc-…--user-0000--api.openshell.localhost:8080/`, both runtime
IDs under `agents`, and the Hermes token path under `interfaces`.
- **CLI:** the port forward and client certificate from
`docs/kubernetes.md`, then `openshell gateway add … --oidc-client-id`
with `OPENSHELL_OIDC_CLIENT_SECRET` (OpenShell 0.1.6): `Authenticated
via client credentials`; `openshell status` showed `Authenticated
(OIDC)`.
  - **Load:** `PROMPTS=12 CONCURRENCY=4 load.sh apply.json`:

    ```text
    Sending 12 prompts to 2 sandboxes, at most 4 at a time:
user-0000: Hermes API at
https://nc-…--user-0000--api.openshell.localhost:8080/
user-0001: fabric-agent-ctl invoke, runtime runtime-1793794887745-82-2

    Sent 12 prompts in 238 s: 12 replied, 0 failed.
    Latency of replies: p50 51.9 s, p95 156 s, max 156 s.

      user-0000 (api): 6/6 replied; p50 16.9 s, p95 87.6 s, max 87.6 s
      user-0001 (invoke): 6/6 replied; p50 80.7 s, p95 156 s, max 156 s

reply #1 user-0000: A Kubernetes HorizontalPodAutoscaler is a service
that automatically scales its pods based on metrics.
reply #2 user-0001: The current system state shows no active exec
sessions or subagents, indicating no ongoing operations are in progress.
To proceed, please check your system or c
    ```

An earlier run of 8 prompts also got 8 replies. OpenClaw's replies don't
answer the prompts, likely because of `qwen3:0.6b` with OpenClaw's
tools; each invocation still reported `succeeded` with a response.
- **Failures:** with `TIMEOUT=5`, both requests were reported as failed
(`curl: (28) Operation timed out` and `timed out after 5 s`), and the
script exited 1.
- Not run: GPUs, autoscaling, vLLM, NIM, and Deep Agents. The Deep
Agents path is the same `fabric-agent-ctl invoke` command as OpenClaw's.
- Deferred to CI: `cargo ci live-kind` and `live-docker`; the change
adds no image or Kubernetes code.

Co-authored-by: maggiezha <42832776+maggiezha@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: ci CI workflows, checks, release automation, or GitHub Actions area: integrations Third-party service integration behavior chore Build, CI, dependency, or tooling maintenance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants