AArch64 Server Promotion
Summary
Promote Aarch64 server technologies to Primary Architecture status. This would include the Server installer, the DVD installer ISOs, the Cloud (qcow2 images) and Docker base images to the same status as other primary Server architectures. This would NOT currently include other components such as Workstation images/installs, any of the various spins, or Fedora Atomic components.
Owner
- Name: Peter Robinson
- Email: pbrobinson@fedoraproject.org
- Name: Paul Whalen
- Email: pwhalen@fedoraproject.org
- Release notes ticket: #114
- Responsible WG: ARM SIG
Current status
Detailed Description
The AArch64 Architecture in the server space is a mature product with numerous platforms widely available for testing. We support both SBSA Enterprise Haware as well as a number of Single Board Computers, initially officially supported in Fedora 27 with the aarch64 SBC Feature, with new device support being added all the time and more widely available and affordable hardware.
The changes is actually a minor one as we already produce all the deliverables as an Alternate Architecture, this primarily be a change of where the output of the artifacts are delivered on the mirrors and making the architecture a release blocking architecture.
This would NOT currently include other components such as Workstation images/installs, any of the various spins, or Fedora Atomic components.
Benefit to Fedora
This feature brings the well supported and now more widely used AArch64 architecture for the Server/Cloud/Docker Base image deliverables to a primary status with wider focus.
Scope
- Proposal owners: The general AArch64 support is already in place and is widely and actively supported by the Fedora ARM SIG and numerous ARM vendors and third parties in Fedora. There will be further and wider support, hardware enablement, polish and general improvements.
- Other developers: N/A: There's no work required for other developers, the aarch64 architecture is already widely supported as an Alternate Architecture.
- Release engineering: Needs approval from release engineering as a primary architecture as well as pungi configuration changes to output artifacts to new location on the primary mirror. rel-eng ticket #7243
- Policies and guidelines: Updates to the primary architectures and release blocking details will need to be updated to reflect that the AArch64 Server/Cloud/Docker components are now considered primary.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
No impact on upgrades, for AArch64 systems running Fedora 27 or older releases the upgrades will be seemless as Mirror Manager will automatically deal with the location of the new Fedora 28 content.
How To Test
Testable in a number of ways. On a supported SBC, such as a Raspberry Pi 3, a SBSA compliant platform, or a cloud provider that supports AArch64 Cloud images. Docker base images can be tested on older Fedora releases or other distributions that support Docker on AArch64. Cloud images can also be booted on an emulated AArch64 machine on x86_64 using libvirt/virt-manager.
We will engage with QA to enable automated testing with the current Fedora automated QA test processes to ensure automated testing across the primary blocking components to the same level as other primary architectures.
User Experience
The AArch64 is similar to x86_64, ARMv7, the current primary architectures, and other Fedora architectures so the user experience is expected to be the same as the other architectures. The install and boot paths are the same across all supported devices using uEFI and grub2 so there's no special cases.
Dependencies
No specific dependencies. The AArch64 promotion is actually very self contained but given a new primary architecture for some Fedora artifacts it's been given a system wide change status.
Contingency Plan
- Contingency mechanism: As the architecture support is already complete, it's already imported into the core koji instance, it's primarily a change in the output locations of the artifacts produces by pungi and a change in status of release blocking components there's not a big requirement of contingency. The fall back would be continue to deliver the Server/Cloud/Docker Base images as they currently are.
- Contingency deadline: Fedora 28 branching point
- Blocks release? Yes: as with the Server/Cloud/Docker Base images will become the same blocking status as the other primary architectures (x86_64/ARMv7)
- Blocks product? Server/Cloud/Docker Base images
Documentation
The core AArch64 documentation at ARM SIG landing page is generally up to date and will likely need minor updates.