NVIDIA / NVIDIA/NemoClaw

Export read-only OpenClaw agents sharing fixed managed vLLM

Open
#11,859 0 comments 0 reactions 1 assignee Claimed by @sandl99 View on GitHub
area: cli enhancement
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 43m
Merged PRs (30d)
718

Description

Parent: #10904. Implementation target: **main**.

## Problem and outcome

A read-only OpenClaw roster cannot currently be exported with the fixed managed-vLLM profile. [Roster projection](https://github.com/NVIDIA/NemoClaw/blob/f5c05a0e6a59bd5133c50e31becbff25af274c33/src/lib/domain/config/verify-export-source.ts) excludes serving-profile provenance, managed profile comparison does not admit the retained roster, and [schema semantics](https://github.com/NVIDIA/NemoClaw/blob/f5c05a0e6a59bd5133c50e31becbff25af274c33/src/lib/config/schema.ts) require a hosted route.

Source baseline: `f5c05a0e6a59bd5133c50e31becbff25af274c33`.

## Before / after

### Before

At the recorded source revision, `vllm-roster` is the existing fixed Nemotron deployment with primary OpenClaw plus a read-only `researcher`, sharing one verified inference route.

```bash
nemoclaw config export vllm-roster --output vllm-roster.yaml
```

Export refuses the combination: roster projection excludes serving-profile provenance, managed profile comparison does not admit the roster, and schema semantics require a hosted route for read-only agents. No document is published.

### After

The same supported deployment exports successfully, including both agents:

```yaml
# spec.sandboxes[0].agents — baseline route settings
- name: primary
type: openclaw
inference:
routes:
- name: primary
providerRef: managed-vllm
overrides:
model: nvidia-nemotron-3.5-lightning-30b-a3b-nvfp4
contextWindow: 65536
- name: researcher
type: openclaw
tools:
allow: [read]
inference:
routes:
- name: primary
providerRef: managed-vllm
overrides:
model: nvidia-nemotron-3.5-lightning-30b-a3b-nvfp4
contextWindow: 65536
```

The full document retains the fixed provider's verified catalog/profile/recipe/model/image identities. With #11854, additional admitted read-only agents follow the same rule. Shared execution settings stay on primary; route tuning supported by #11856 is preserved consistently across the roster.

A divergent route/model/context, unsupported secondary setting, missing or inconsistent roster authority, or changed serving identity still refuses the whole export. The action regression and existing managed-vLLM qualification must verify both roster fidelity and provider identity without recreating agents or inference resources.

## Scope

The existing Linux/AMD64, Docker, fixed Nemotron deployment with primary plus read-only secondary agents, sharing exactly one verified inference route. Build on #11854 and coordinate shared managed-setting projection with #11855 and #11856.

## Acceptance

- Export primary plus researcher with a shared fixed-profile route and preserved read-only tools.
- Preserve every admitted secondary when 1..* support is present; keep shared execution/interfaces/observability on primary.
- Preserve the 65536 context window and the verified catalog, profile, recipe, image, model revision and served name.
- Reject route/model differences, missing or inconsistent roster authority, serving drift and unsupported secondary settings.
- Exercise the full action and add a roster case to existing managed-vLLM qualification; schema-only acceptance is insufficient.

No new profiles, GPUs, runtimes, agent types or independently routed agents are included.

## Delivery boundary

Extend the existing observation → verification → document builder → schema → publication pipeline. Export remains read-only and emits credential references only. Preserve successful existing exports and refusals for unrelated unsupported state. Regenerate the checked-in schema when its source changes.

Use a failing behavioral test before implementation, focused schema/action tests, and an existing installed-CLI scenario for the real boundary. Reuse coverage work in #11485; branch-to-branch translation and deployment parity remain with #11810. This issue does not add config-driven apply, resource adoption, or change existing onboarding inputs.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.