Feature Overview:

For RHEL AI we focused on complete ownership of the image content and built specialized wheel and image pipelines for building the product without a midstream. This approach will not work well for RHOAI, which already has a strong midstream presence. We need to make some adjustments in our images, make some new images, and provide our wheel packages in the midstream build environment to allow RHOAI adoption of the builds we are doing.

Product(s) associated:

RHOAI

Goals:
Provide high-level goal statement with user context and expected user outcome(s) for this Feature

• RHOAI developers will continue to own their image content using approaches familiar to them from working with upstream packages and images.
• AIPCC developers will be assured that new dependencies added in the midstream will trigger notifications for downstream builds very early in the process.

Requirements:
A list of specific needs, capabilities, or objectives that a Feature must deliver.

1. We want a single Containerfile (per variant?) for each component image to be able to build the ODH midstream build with upstream wheels and the RHOAI downstream builds with AIPCC wheels.

This implies the process for installing wheels is the same, and is compatible with simple pip install commands like would be used upstream.

This implies that base images used for the midstream and downstream builds are compatible from the perspective of installing dependencies and wheels.

This implies that any base images produced by AIPCC for the downstream build have all of the needed RPM dependencies in them, or the component images install those dependencies in both builds.

There will be some build parameters for the image, to support the differences between upstream and downstream, but ideally we won’t need separate logic in the Containerfile.

2. We want base images that can be released freely in the midstream builds.

These images need to be compatible in the sense that someone can use them to build similar images, but it is not necessary that they are ABI compatible with AIPCC wheels.

3. We want a way to host the full set of all wheels that can be used to build RHOAI images so it is accessible to midstream builds.

These packages do not need to go into the ODH release.

4. We want to manage updates to base images and the package index for z-stream releases.

Done - Acceptance Criteria:
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view

1. ODH (midstream) and RHOAI (product) builds for a given image can use a common Containerfile in a single git repository.
2. ODH builds of images with Python-based components use a few common base images consistently.
3. ODH builds of images with Python-based components use upstream wheels.
4. RHOAI builds of images with Python-based components use AIPCC base images.
5. RHOAI builds of images with Python-based components use AIPCC wheels.
6. Adding dependencies in the midstream that are not available downstream (RPM, wheel, etc.) trigger build failures of RHOAI midstream builds and Jira tickets are filed (manually or automatically) requesting the new package.

Use Cases - i.e. User Experience & Workflow:
Include use case diagrams, main success scenarios, alternative flow scenarios.

Out of Scope:
High-level list of items or personas that are out of scope.

Documentation Considerations :
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation.

Other Documentation:

* RHOAI Adoption of AIPCC Roadmap