Design: port deployment scripts to rossoctl-cli

[kellyaa]

Summary

Replace direct kubectl calls in the deployment scripts (deploy-agent.sh, deploy-benchmark.sh, delete-all-deployments.sh, authbridge/apply-pipeline.sh) with rossoctl-cli commands. Goals: (1) remove the kubectl/kubeconfig dependency so the harness can target a shared rossoctl API server, and (2) collapse ~4,600 lines of bash + CR boilerplate onto a supported CLI.

Also drops MCP gateway support from the harness — see below.

Scope

In scope:

• deploy-agent.sh — currently 16 kubectl calls
• deploy-benchmark.sh — currently 21 kubectl calls
• delete-all-deployments.sh — currently 5 kubectl calls
• authbridge/apply-pipeline.sh — currently 9 kubectl calls (authbridge is being renamed cortex; same component)

Out of scope: analyze-run.sh, evaluate-benchmark.sh, update-secrets.sh (arbitrary secret CRUD — no rossoctl surface, and not on the main deployment path).

Removed as part of this work: --use-mcp-gateway support in deploy-agent.sh and deploy-benchmark.sh. The gateway-registration path (creating HTTPRoute + MCPServerRegistration CRs, polling for Ready) is no longer needed. Tools attach to agents directly via the tool's service.

Mapping to rossoctl-cli

Available today:

Current	Replacement
kubectl apply of Agent CR	rossoctl agents import from-image --name … --containerImage … --envVarsURL …
kubectl apply of Tool CR	rossoctl tools import from-image --name … --containerImage … --ports … --envVarsURL …
kubectl delete agent/tool	rossoctl agents delete <name> / rossoctl tools delete <name>
kubectl get agents/tools -A	rossoctl agents list -A / rossoctl tools list -A
kubeconfig context switching	rossoctl config use-context / rossoctl login
Readiness wait	Poll rossoctl agents get <name> (or keep the existing HTTP health-check on the agent card)

Blocker — feature rossoctl-cli needs before apply-pipeline.sh can be deleted

Cortex sidecar control on agent create. The rossoctl operator auto-injects the cortex sidecar when an Agent CR is reconciled, but there is no way to (a) opt out, or (b) supply per-plugin configuration. Today deploy-agent.sh works around this by calling authbridge/apply-pipeline.sh as a post-create step, which reads a base ConfigMap in the target namespace, merges user YAML on top, and waits for the Envoy sidecar to reload.

Proposed rossoctl surface:

rossoctl agents import from-image … \
  --cortex=on|off \
  --cortex-plugin <name>=@<file>   # repeatable

Wire-format additions: cortexEnabled bool and a per-plugin config map on CreateAgentRequest. The operator honors these on reconcile.

Without this feature: apply-pipeline.sh stays on kubectl and cannot be deleted.

Local-dev cluster patches (out of scope for rossoctl)

deploy-agent.sh and deploy-benchmark.sh also patch imagePullPolicy: IfNotPresent, set CPU/memory limits, and patch HTTPRoute targetPort — workarounds for Kind local-dev, not rossoctl's job. Two options:

• Move them into a libsh/local-dev-patches.sh gated on --local, keeping kubectl for them; or
• Push sensible defaults into the operator so they aren't needed.

Proposed approach

Phased so partial value lands without waiting on upstream:

• Phase 1 — replace CR create/delete/list in all three deploy/delete scripts with rossoctl. Drop --use-mcp-gateway from deploy-agent.sh and deploy-benchmark.sh. Isolate local-dev patches behind a --local flag. Non-blocking: no rossoctl feature deps.
• Phase 2 — delete authbridge/apply-pipeline.sh entirely, replaced by --cortex-plugin flags on agents import. Gated on the cortex-sidecar rossoctl feature.

End state: no kubectl on the main deployment path. Local-dev cluster patches either stay behind --local or are eliminated at the operator level.

Motivation

• Portability: the harness can currently only run against a cluster where the user has kubeconfig access. Shared OpenShift rossoctl deployments (per the rossoctl-cli README's --server usage can't be targeted at all.
• Simplification: the four scripts total ~2,250 lines, most of which is YAML heredocs, retry loops, and ConfigMap merging that rossoctl (or its operator) should own.
• Auth-path parity: the harness would exercise the same API server + auth code path real users hit via the web UI, rather than a parallel kubectl-based one.

Related

• rossoctl-cli feature request (to be filed separately): cortex sidecar config on agent create.
  EOF
  )