From Fedora Project Wiki
No edit summary
 
(11 intermediate revisions by 2 users not shown)
Line 27: Line 27:
== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
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.
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 ==
<!--
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
This should link to your home wiki page so we know who you are.
-->
== Owner ==
== Owner ==
* Name: [[User:pbrobinson|Peter Robinson]]
* Name: [[User:pbrobinson|Peter Robinson]]
Line 39: Line 34:
* Name: [[User:pwhalen|Paul Whalen]]
* Name: [[User:pwhalen|Paul Whalen]]
* Email: pwhalen@fedoraproject.org
* Email: pwhalen@fedoraproject.org
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/114 #114]
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
-->
* Responsible WG: ARM SIG
* Responsible WG: ARM SIG
== Current status ==
== Current status ==
* Targeted release: [[Releases/28 | Fedora 28 ]]  
* Targeted release: [[Releases/28 | Fedora 28 ]]  
* Last updated: 2017-11-02
* Last updated: 2018-01-06
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 55: Line 51:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracking bug:
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1537251 #1537251]


== Detailed Description ==
== Detailed Description ==
Line 64: Line 60:


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.
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 ==
== Benefit to Fedora ==


This feature  
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.
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->


Line 77: Line 75:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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. [https://pagure.io/releng/issue/7243 rel-eng ticket #7243] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook  -->
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook  -->
Line 110: Line 108:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
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.
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 ==
== User Experience ==
Line 125: Line 125:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) Feature is already mostly complete, upstream stable release is scheduled will within the required release window <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Fedora 28 branching point<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? Server/Cloud/Docker Base images <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
Line 136: Line 136:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
The core AArch64 documentation at [[Architectures/ARM | ARM SIG landing page]] is generally up to date and will likely need minor updates.


== Release Notes ==
== Release Notes ==
Line 145: Line 145:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF28]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 15:09, 2 March 2018



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.

Release Notes