[RFC][Batch]: Add ModelAdapter management to AIBrix Console

Summary

This RFC proposes adding open-source LoRA ModelAdapter management to AIBrix Console.

The Console will provide a Kubernetes-backed BFF and UI for discovering existing base-model Deployments and listing, creating, inspecting, and deleting ModelAdapter resources.

The initial scope supports standard Kubernetes Deployments, existing ModelAdapter artifact URL schemes, and the two placement modes already defined by the CRD. It does not modify the ModelAdapter CRD or controller APIs

Motivation

AIBrix already supports dynamic LoRA loading through the ModelAdapter CRD and controller, but operators currently need to construct resources manually with kubectl.

This requires users to understand pod selectors, base-model identifiers, engine ports, placement semantics, and ModelAdapter status fields. Incorrect selectors or identifiers can create resources that never bind to a serving Pod.

The Console should provide a standardized workflow that derives these fields from an existing Deployment, while keeping Kubernetes and the ModelAdapter controller as the source of truth.

This improves usability and operational visibility without introducing another persistence model or changing the existing AIBrix APIs.

Proposed Change

Backend

Add a narrow REST BFF:

• GET /api/v1/model-adapter-targets
• GET /api/v1/model-adapters
• GET /api/v1/model-adapters/{name}
• POST /api/v1/model-adapters
• DELETE /api/v1/model-adapters/{name}

The BFF will:

1. Reuse the Deployment provider's kubeconfig, context, and namespace.
2. Discover Kubernetes Deployments with deterministic matchLabels selectors.
3. Derive baseModel, podSelector, engine, serving port, and runtime target information server-side.
4. Map "all matching Pods" to omitted spec.replicas and "single Pod" to spec.replicas: 1.
5. Validate names, placement, and artifact URLs against existing open-source ModelAdapter behavior.
6. Enrich ModelAdapter responses with Deployment and bound-Pod status.
7. Delete only the ModelAdapter resource. The controller remains responsible for unloading the adapter, while the base Deployment remains unchanged.

Model identifiers that cannot be represented as Kubernetes label values will use the stable Deployment name in spec.baseModel; the UI will continue displaying the original model identifier.

Frontend

Replace the LoRA placeholder with:

• ModelAdapter list and search
• Deployment discovery
• LoRA creation form
• All-Pods and single-Pod placement selection
• ModelAdapter status and bound-Pod details
• ModelAdapter deletion

Scope

This RFC does not add internal service providers, artifact uploads, CRD changes, controller changes, or base-model Deployment lifecycle management.

Alternatives Considered

No response

Start with the Deployment provider, the existing ModelAdapter CRD and controller APIs, and the LoRA placeholder in the Console. Trace the proposed REST entry points and deployment-derived fields before checking how the UI should consume them. Done means the listed discovery, CRUD, placement, status, and deletion workflows work without changing the CRD, controller, or base Deployment lifecycle.