-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
golang-to-typescript
-
False
-
-
False
-
-
To Do
-
RHDHPLAN-944 - [Spike] investigations, code pocs, upstream engagements for connector upstream plugin
-
QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
-
75% To Do, 0% In Progress, 25% Done
-
-
EPIC Goal
Produce a demo-able version of the connector that is entirely in typescript and packaged as a backstage plugin
Background/Feature Origin
convert our existing connect as is, with all the kserve/kubeflow integrations and algorithms predominantly being independent of backstage particulars, or reasonably abstracted, save that in redhat-ai-dev, and then see the outcome of our upstream engagements wrt what modifications are needed.
Claude code has already proven to be a useful tool in accelerating / quasi-automating this, and I have a branch that is a decent bit along.
Also, integrations like techdocs, pending ODH/Kubeflow particulars, will most likely be missing initially. Due diligence around this with RHOAI is needed to confirm/deny.
With this initial take, we will use the k8s typescript SDK directly, including the informer API we investigated during devtools week in 2025.
Why is this important?
Need to actually provide the code.
User Scenarios
- Import models/modelservers from RHOAI like the original connector does
- Import from local deployments running kind/kubeflow/kserve as needed to validate a complete upstream experience
Dependencies (internal and external)
- RHOAI cycles for confirmation on techdoc presence in upstream vs. midstream/downstream
Acceptance Criteria
- branch off of redhat-developer/rhdh-plugins or an update to our redhat-ai-dev/rhdh-plugins (final call could depend on how many of us work this
- demo video
- clones
-
RHIDP-11685 Upstream engagement on how to map AI Model Servers to the Backstage catalog
-
- In Progress
-
- is cloned by
-
RHIDP-11687 Kuberenetes client usage upstream (backstage plugin vs. k8s typescript sdk)
-
- New
-