EPIC Goal

Get as much recommendation as possible from upstream maintainers and SMEs on backstage plugin usage vs. direct k8s typescript SDK usage

Background/Feature Origin

The k8s plugin in core leverages parts of the k8s typescript SDK, but they bypass large portions of it, and have writtern their own REST client for interacting with k8s

In discussion with COPE, they have no awareness of why.  The educated guesses aligned with mine, in that it could be that the k8s SDK was too immature etc. when the k8s plugin was built.  Or the frontend / UI integration necessitated the implementation choices.

Meanwhile, in the community plugins, there is a mixture of plugins that either use the backstage k8s plugin wholesale, or instead the use the k8s SDK.

So far, it appears to me to depend on whether your plugin provides frontend changes.  For example,

• tekton provides UI, uses the backstage k8s plugin
• ocm does not, and uses the SDK

Potentially, the output from the BEP could have bearing here, in that 

• if we can move forward as a community plugin, we can use the SDK, which is much more straight forward
• if we are directed toward including in core backstage, we'll have to see where things land ... does being in core absolutely mean we HAVE to use the plugin?

In the interim, this portion of the feature needs to :

• complete some due diligence investigation into confirming why backstage did what they did
  • git history mining
  • open issues that ask the question as to what happened
  • discussion topics in framework sig
• STRETCH: gauge the viability of modernizing the k8s plugin if that in fact helps us with this feature long term
  • Paul S. from COPE says they are looking for a maintainer upstream

Why is this important?

Community compliance wrt k8s interaction will benefit consumption of our work.

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)

• Upstream maintainers and SMEs providing relevant history and recommendations 

Acceptance Criteria

• document approach for both our use and general RHDH use
• if applicable, update output from RHIDP-11686