Story (Required)

As a AI platform engineer trying to provide AI model to my org's application developer  I want an uniform mapping of the metadata from 3Scale' REST API / CRDs for AI model managed by 3Scale to the proscribed API for expressing AI Model in the Backstage Catatlog.

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

Background (Required)

Under RHDP-1014 we created a Model Catalog API.  And then under stories like DEVAI-139 and DEVAI-140 we took what was available from Kubeflow Model Registry REST API and ultimately  created Backstage catalog-info.yaml files (with the 'bac' CLI for example) that conformed to the Model Catalog API defined under RHDH-1014.

We want to start a similar exercise with Models hosted in 3Scale (a la the RH internal MaaS) in place of Kubeflow as the "Model Registry".

Out of scope

Approach (Required)

3Scale has a [CLI written in Ruby that wraps its administrative REST API.  When deployed on OCP, there are Operator CRDs that map to all the 3Scale types like Products, Backends, etc.  That, along with examining OCP API like Routes, could provide useful information and sufficient metadata for the model catalog. and document how it maps to the model catalog API defined at 

https://docs.google.com/document/d/1ArB8w-TawZ_DuMbZoukk4inVsAgqHntB8yN2lttwjyo/edit?tab=t.0#heading=h.vb3kc1uzrgdu  

Dependencies

Acceptance Criteria (Required)

• A google document under https://drive.google.com/drive/folders/1ETbQCGc0LJFsH0zBqs2V2c_gfSfq5ziY that details the mapping, with green/orange/red to indicate what is obviously available from the 3Scale REST API/CRDs (green), what is maybe available, but you need to squint at it (orange), and what if anything does not appear available (red)
• stretch goal: produce a catalog-info.yaml file built from data pulled for one of the IBM granite 3.x models stood up in 3Scale (a la MaaS) that (manually if need be, tooling if possible ) can be imported into RHDH
  • Unit Tests if not manually created.

documentation updates (design docs, release notes etc)
demo needed
SOP required
education module update (Filled by RHDHPAI team only)
R&D label required (Filled by RHDHPAI team only)

Done Checklist

Code is completed, reviewed, documented and checked in
Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
Continuous Delivery pipeline(s) is able to proceed with new code included
Customer facing documentation, API docs, design docs etc. are produced/updated, reviewed and published
Acceptance criteria are met
If the Grafana dashboard is updated, ensure the corresponding SOP is updated as well