Skip to content

feat(web): select model catalogs per canary arm - #99

Merged
aceforeverd merged 1 commit into
modelsphere:release-canaryfrom
primowenjoy:feat/canary-arm-catalog
Oct 25, 2026
Merged

aceforeverd merged 1 commit into
modelsphere:release-canaryfrom
primowenjoy:feat/canary-arm-catalog

Conversation

@primowenjoy

Copy link
Copy Markdown

What type of PR is this?

  • feature

What this PR does and why

Canary arms previously listed models from the default catalog only. Each arm now chooses its own model catalog before choosing a model and variant, using the existing authenticated Swiss /cluster and named /catalog endpoints.

  • Default to upstreamv2 when configured, otherwise a supported environment default or first supported catalog.
  • Keep v1 catalogs visible but disabled; Canary requires v2 variants.
  • Scope model lists and chart-version queries to the arm catalog. Switching catalogs clears its model, variant, chart pin and YAML overrides, including YAML errors.
  • Add searchable model selection, localized loading/error/empty states and retry. Block progression and preparation until selection is ready.
  • Update English/Chinese instructions and document the selection behavior.

Which issue(s) this PR fixes

Fixes #98

How it was tested

  • npm run typecheck, npm test (485 tests / 58 files), npm run build.
  • go test ./..., go vet ./..., gofmt and git diff --check.
  • Deployed to the test cluster with an image-only Helm upgrade; both Console replicas are ready.
  • Chrome: default catalog, disabled v1 option, exact model-list isolation, switching catalogs with the same model name, old YAML/pin reset, independent arm selections and English/Chinese copy. Slow cluster response regression checks ensure arms cannot be added before catalog defaults are ready and default variant labels remain visible.
  • Real prepare request with the same model from upstreamv2 and inner returned 201. Frozen Swiss plans retain the two distinct catalog names and variants; GPU models were prepared only.
  • Browser fault injection: loading, HTTP 503 and an empty catalog block progression; retry restores the selected catalog's models.
  • Browser-created CPU Mock experiment reached Serving with 2/2 arms. Generated HTTPRoute was Accepted/ResolvedRefs, and a forced request returned HTTP 200. Temporary resources and identity are cleaned up after validation.

Checks

  • go test ./... and gofmt -l . is empty
  • npm run typecheck && npm test && npm run build in web/
  • Docs updated where behavior moved
  • No internal hostnames, IPs, registries or credentials

Notes for reviewers

Base is release-canary, which contains the Canary module. This PR contains only catalog selection. The test deployment also retains the existing environment-default wizard changes from #97; those changes are not included in this diff.

Start with CanaryCreate.tsx, then the authenticated catalog transport and reset/default tests. No backend API, config key or CRD changes.

Release note

Canary experiment arms can independently select a v2 model catalog and then a model within it, defaulting to upstreamv2 when available.

Read v2 catalogs from Swiss cluster configuration, default to upstreamv2, and scope model, variant and chart selection to each arm catalog. Reset source-specific configuration when switching catalogs.
@aceforeverd
aceforeverd requested a review from huskcass October 25, 2026 06:11

@huskcass huskcass left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blockers at 8dea0fd.

Verdict: per-arm catalog selection is wired end to end (Swiss /cluster and named /catalog, chart-versions and prepare all carry the arm's catalog) and the reset on catalog change is correct; typecheck and web tests pass.
— Review Golden

@aceforeverd
aceforeverd merged commit 3b96980 into modelsphere:release-canary Oct 25, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants