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

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

XMLWordPrintable

    • [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
    • rhel-sst-container-tools
    • 13
    • False
    • Hide

      None

      Show
      None
    • Yes
    • QE ack, Dev ack, Docs ack, PXE ack
    • Enhancement
    • Hide
      .Building multi-architecture images is fully supported

      The `podman farm build` command that creates multi-architecture container images is now fully supported.

      A farm is a group of machines that have a unix Podman socket running in them. The nodes in the farm can have different machines of various architectures. The `podman farm build` command is faster than the `podman build --arch --platform` command.

      You can use `podman farm build` to perform the following actions:

      * Build an image on all nodes in a farm.
      * Bundle an image on all nodes in a farm up into a manifest list.
      * Execute the `podman build` command on all the farm nodes.
      * Push the images to the registry specified by using the `--tag` option.
      * Locally create a manifest list.
      * Push the manifest list to the registry.

      The manifest list contains one image per native architecture type present in the farm.
      Show
      .Building multi-architecture images is fully supported The `podman farm build` command that creates multi-architecture container images is now fully supported. A farm is a group of machines that have a unix Podman socket running in them. The nodes in the farm can have different machines of various architectures. The `podman farm build` command is faster than the `podman build --arch --platform` command. You can use `podman farm build` to perform the following actions: * Build an image on all nodes in a farm. * Bundle an image on all nodes in a farm up into a manifest list. * Execute the `podman build` command on all the farm nodes. * Push the images to the registry specified by using the `--tag` option. * Locally create a manifest list. * Push the manifest list to the registry. The manifest list contains one image per native architecture type present in the farm.
    • Done

      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
         

       

       SME: Urvashi Mohnani, Nalin Dahyabhai

              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:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: