Task

As an engineer working on RHDH, I want to understand as best as possible how the backstage k8s plugins's use of the k8s typescript sdk so that new plugins interfacing with k8s employ community endorsed methodologies.

Background

During Gabe Montero's initial dive into the backstage k8s plugin code, he discovered that while it uses the k8s typescript library, it did NOT use the 'makeApiClient' API, and in fact had implemented its own REST client for interfacing with the k8s REST API.

Then, in the community plugins, he noticed a mixture of 

• plugins typically with a UI element using the k8s pluging
• catalog entity provide plugins using the k8s sdk directly, including makeApiClient

Dependencies and Blockers

No QE or Doc impacts

Acceptance Criteria

Using any historical context from RHIDP-11762, through a combination 

• opening upstream issues to ask for confirmation/clarification around what our research uncovered
• adding framework SIG agenda items to similarly confirm or deny
  • with the understanding that finding a k8s plugin maintainer per intel from COPE team could filter into the discussion
  • including perhaps new features to have the k8s plugin use more of the SDK

nail down community preferences and recommendations, both for core and community repos, on when to use the backstage k8s plugin vs. the k8s typescript SDK