fix(enterprise): carry the provider through, and point cube-cos at the dashboard

[traviswu-bigstack]

/kind bug

What

install-advisor.sh now carries the inference provider through a re-run, and points the cube-cos web-console target at the dashboard instead of loopback.

Why

Both were found installing the advisor on the 1cc r630, and both presented as a surface that looks configured and fails anyway.

The provider reset itself on every re-run. This script renders the whole release, so a value it does not pass back is one helm removes — and it passed nothing for the provider. Each deploy reset provider.url to the chart's placeholder and dropped the key, after which the UI still reported chat as enabled and every question failed. It now reads the key back from the cube-advisor-secrets Secret and the URL from the deployment's arguments, the same way it already carries the TLS and enrollment material, and accepts both as arguments (7 and 8) so a first install can set them.

The URL read-back is a positional lookup in the argument list rather than a jsonpath range piped through grep: the latter silently produced nothing, which carried the key correctly while letting the URL fall back to the placeholder — a failure indistinguishable from not having tried.

cube-cos pointed at http://127.0.0.1:8080. That port is httpd, which answers 403 to everything; nginx serves the dashboard on the control address. A target pointed at loopback looks configured and refuses every request, with nothing in any log to say why — in the browser it presented as the proxied tab showing "403 Forbidden". It now uses the control address the script already resolves for the kubeconfig.

The node-side half of the same bug — the seeded default in sdk_advisor.sh — is in cubecos #1482.

Also: the endpoints the dashboard links out to

The cube-cos origin now declares three companions on other ports of the same pinned address — Keycloak (:10443), Skyline (:9999) and the Ceph dashboard (:7443). All three are linked from the dashboard's home page and all three are built in script from the cluster address it hands over as a bare string, so a browser following one left the proxy origin for an address a remote operator cannot reach. They share the origin's address, so they are further ports on the load balancer that already exists rather than three more.

The proxy-side support is bigstack-oss/cube-ai-advisor#227; the node-side allowlist entry is bigstack-oss/cubecos#1482. Verified in a browser on the r630: the CubeCOS login page renders at https://10.32.1.61:10443/…, signing in lands on https://10.32.1.61/home, and every link on that page is then on 10.32.1.61 — Skyline and the Ceph dashboard included, both of which render through the proxy.

Also: the CMP portal's landing path

The CMP origin now sets path: /portal. The framework ingress serves the portal under that prefix and Keycloak under /auth, and claims nothing at the root, so the origin opened at / landed on the ingress's own 404.

Testing

• go test ./... clean.
• Two cases added in internal/enterprise/assets_test.go: the script reads the key back and says so, and it does not point cube-cos at loopback.
• Verified on the 1cc r630: re-ran the installer without provider arguments, the deployment kept -provider-url https://api.anthropic.com/v1 and its key, and chat answered. The cube-advisor-web-console ConfigMap reads upstream: https://10.32.1.200 for the 10.32.1.61 origin, and that origin serves the CubeCOS dashboard.

Reviewer notes

The helm invocation gained "${PROVIDER_ARGS[@]}". The array is empty when there is nothing to carry and nothing was passed, so a first install with no provider is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PZ5umjjCedZwWtbAbiMjfj

---

Tracked by #117.