Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-34611

[RHEL EPIC] Podman multi-arch buildfarm feature - GA RHEL 10.0 Beta

    • [RHEL EPIC] Podman multi-arch buildfarm feature - GA RHEL 9.5
    • Hide

      The following needs to be verified in order for this epic to be considered complete:

      • Use the established tests from RHEL 8.10/9.4 for verification purposes.
      Show
      The following needs to be verified in order for this epic to be considered complete: Use the established tests from RHEL 8.10/9.4 for verification purposes.
    • Red Hat Enterprise Linux
    • sst_container_tools
    • 13
    • False
    • Hide

      None

      Show
      None
    • Yes
    • QE ack, Dev ack, Docs ack, PXE ack
    • Enhancement
    • TBD

      Description

      In some environments, developers need to be able to produce the same container image for multiple CPU architectures. We want to enable developers with access to hardware of various architectures to be able to take advantage of podman's remoting capabilities to create multi-arch ready builds on that hardware in an easy to use way. For RHEL 8.10 and RHEL 9.4 (Podman v4.9), this will be a Tech Preview Feature in RHEL.

       

      As this feature was completed as a Tech Preview in RHEL 8.10/9.4, the work for this feature will mostly consist of adjusting the RHEL documentation to show it is now GA, and to also possibly add a release note.  For QE, it will just be a test to make sure the multi-arch build functionality is still working.

      Requirements

      Have one podman environment be able to hand off builds for other architectures to systems connected via podman system connections. Once connections are properly established, it should be a single command to trigger builds on all enabled architectures.

       

      requirement Notes isMvp?
           
           
           

       

      (Optional) Use Cases
      Out of ScopeDocumentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      <What does success look like?>

      < Does this feature have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

       <If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

      • <What concepts do customers need to understand to be successful in [action]?>
      • <How do we expect customers will use the feature? For what purpose(s)?>
      • <What reference material might a customer want/need to complete [action]?>
      • <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >
      • <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

       

      Interoperability Considerations

      < Which other products and versions in our portfolio does this feature impact? >

      <If other products will be impacted set the 'LP_Interop' label on the Feature>

      < What interoperability test scenarios should be factored by the layered product(s)? >

       

      Questions

      Question Outcome
         

       

       

            tsweeney@redhat.com Tom Sweeney
            tsweeney@redhat.com Tom Sweeney
            Container Runtime Eng Bot Container Runtime Eng Bot
            Container Runtime Bugs Bot Container Runtime Bugs Bot
            Gabriela Necasova Gabriela Necasova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: