-
Initiative
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
False
-
-
True
-
88% To Do, 0% In Progress, 13% Done
-
XL
-
Feature Overview (mandatory - Complete while in New status)
We need better visibility into what we are building, what changes are in each artifact, and which artifacts map to which RC and GA versions. We should build a dashboard to help us find this information.
Goals (mandatory - Complete while in New status)
- Track the content of all image builds, RHEL AI drops (including multiple related images), wheel collection builds, etc.
- Track builds in progress.
- Find related artifacts for RC and GA builds.
- Find builds containing specific changes based on git SHA or Jira ticket ID
Requirements (mandatory -_ Complete while in Refinement status):
Requirement | Notes | isMVP? |
---|---|---|
Which images and other artifacts are part of a given RC, GA, or z-stream build ? | yes | |
Which image has a fix based on Jira ticket? | ||
Which image has a fix based on git commit SHA? | ||
What changes are in an image build (how is it different from the previous successful build, which Jira tickets are relevant, which git commits in the various repositories are relevant, etc.)? | yes | |
Which version of a wheel is in a given image? | ||
Which images include a given version of a wheel? | ||
Which models are being used by a given version of the product? | ||
What builds, of any type, are happening right now? | ||
How does someone find the build history (link into konflux?)? | ||
Which builder image was used to produce a wheel build that went into an image? | ||
Which base images were used to produce a product image, and what changes are included there? | yes | |
Which versions of our platform components make up a platform release? | yes | |
Which RPMs, and which versions are in a platform release? |
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
The QE team can determine which images to test without asking the release team.
The release manager can select artifacts as candidates and then that content can be promoted or rebuilt for the release.
Component teams (RHEL AI, RHOAI, etc.) can select versions of the platform and see what they support (accelerator library versions, wheel constraints, etc.).
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
As a developer working on a fix, I can tell if my changes made it into a release candidate build.
As a QE engineer verifying a fix, I can tell which image(s) include the fix so I know what to test with.
As a release manager, I can tell what builds are available as release candidates and what is in them.
As a user of the AI Dev Platform, I can find a version that supports what I need in my image (accelerator version, wheel version, etc.).
Out of Scope {}{}(Initial completion while in Refinement status):
- The dashboard does not need to let us trigger builds.
- The dashboard should not reproduce state available in Jira (but it might link to Jira for more info).
- The dashboard should not reproduce state available in Brew (but it might link to Brew for more info).
Documentation Considerations {}{}(Initial completion while in Refinement status):
We need to produce documentation about the components available in the AI platform. We should include the versions and any limitations (such as features not included in the build). We will want to keep this documentation up to date over time, so if we can automate it that would be best.
Questions to Answer {}{}(Initial completion while in Refinement status):
How do we define a "build" that encompasses the entire RHEL AI product, at least for a single accelerator? Users consume the product starting from an installation image or a bootc image, for example, but those rarely have the most significant changes between versions of the product since most of the code is in the instructlab image.
How do we use a dashboard like this for RHOAI builds, too?
Background and Strategic Fit (Initial completion while in Refinement status):
https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com is the dashboard for OpenShift's releases
Customer Considerations {}{}(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>
Team Sign Off (Completion while in Refinement status)
- All required Epics (known at the time) are linked to the this Feature
- All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
- Add - Reviewers name, Team Name
- Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
- Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone
*An engineer or tech lead from the product requesting this feature is required for the signoff below.
Reviewed By | Team Name | Accepted | Notes |
dhellman@redhat.com | Author | ||
- …