From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
No edit summary
Line 54: Line 54:
== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
The Changing IT landscape has started to focus on greener technologies. One thing thats changing due to this is that ARM cpu's traditionally the domain of embedded and mobile applications are finding themselves moving into the desktop, notebook and server markets.  Fedora ARM works on many different devices.
For this change we will enable armv7hl builds on primary koji, and compose arm trees alongside of x86 ones.  Fedora has in the Phoenix data centre 96 quad core calxeda server nodes each had a quad core 1.4ghz soc, 4gb ram and 250gb hdd.  Some of these nodes will remain in the arm koji for building updates for fedora 18 and 19 though when support for Fedora 18 drops some of the nodes will be able to be reallocated. Infrastructure has expressed an interest in trying some of its workloads on ARM, some are for QA, some for releng, there is currently 24 nodes configured in primary koji ready to go as builders, we can add 24 more when ARM becomes primary if desired.
we have moved the kernel to a unified kernel we now build a LPAE and base variant, the same as i686. There is a ARM specific kernel maintainer working in the fedora Kernel team. Release's are composed using the exact same tooling as primary. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take the same shape as livecds on primary but are shipped as a oem disk image, where initial-setup is used to do final user configuration. pungi generates a install tree the same as it does for primary, we are creating pxe install trees only as u-boot does not understand isofs.


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- 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?-->
Enables fedora to embrace the emerging arm world. There is currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and newer devices are all arm based.
Enables fedora to embrace the emerging arm world. There is currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and newer devices are all arm based. Calxeda based servers are shipping today. We could look at having tablet spins in the future but that is currently outside the scope of this Change.  we will be adopting and embracing the the future.  


== Scope ==
== Scope ==
Line 65: Line 71:
Build hardware already exists in phx2 and is configured to talk to koji.
Build hardware already exists in phx2 and is configured to talk to koji.


* Proposal owners:  
* Proposal owners: change the arches in koji, import the matching rawhide builds into koji. update release Engineering scripts to automatically build armhfp trees along with i386 and x86_64
<!-- What work do the feature owners 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 the feature owners 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?-->


* Other developers: submit builds as normal, in the event of unexpected build failures talk to the arm team to help debug and fix issues
* Other developers: submit builds as normal, in the event of unexpected build failures talk to the arm team to help debug and fix issues
<!-- 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: Releng will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are the people proposing the Change.
<!-- 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.  -->
 
 
* Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji


* Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


Line 96: Line 103:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
there are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also.
there are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported arm system should work as it does today for ARM as a secondary arch.


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
User experience really does not change. the difference will be the path in which they use to download files from on the mirrors.
User experience does not change. The only difference will be the path in which they use to download files from on the mirrors.


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
 
There are no special depeendencies.
Hardware in Phoenix is already installed, there is release engineering boxes for doing composing on, there is hardware available for QA use.




== Contingency Plan ==
== Contingency Plan ==
<!-- 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?) If for some reason  
* Contingency mechanism: (What to do?  Who will do it?) if for some reason we fail horribly at migrating into primary we would go back to secondary,  the fix would be removing armv7hl from the build arches by Release Engineering
<!-- 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:  
* Contingency deadline: Alpha
<!-- 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?  Yes  
* Blocks release?  Yes  
Line 133: Line 141:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
 
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]

Revision as of 15:54, 8 July 2013


ARM as primary Architecture

Summary

Make ARM a primary architecture. add armv7hl to the i686 and x86_64 as arches that we build every package for. This will mean that all packages must build for ARM to be released. As of Fedora 19 we have dropped support for software floating support so we are only talking about adding hardware floating point 32 bit support.

Owner

Current status

  • Targeted release: Fedora 20
  • Last updated: 2013-07-02
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

The Changing IT landscape has started to focus on greener technologies. One thing thats changing due to this is that ARM cpu's traditionally the domain of embedded and mobile applications are finding themselves moving into the desktop, notebook and server markets. Fedora ARM works on many different devices.

For this change we will enable armv7hl builds on primary koji, and compose arm trees alongside of x86 ones. Fedora has in the Phoenix data centre 96 quad core calxeda server nodes each had a quad core 1.4ghz soc, 4gb ram and 250gb hdd. Some of these nodes will remain in the arm koji for building updates for fedora 18 and 19 though when support for Fedora 18 drops some of the nodes will be able to be reallocated. Infrastructure has expressed an interest in trying some of its workloads on ARM, some are for QA, some for releng, there is currently 24 nodes configured in primary koji ready to go as builders, we can add 24 more when ARM becomes primary if desired.

we have moved the kernel to a unified kernel we now build a LPAE and base variant, the same as i686. There is a ARM specific kernel maintainer working in the fedora Kernel team. Release's are composed using the exact same tooling as primary. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take the same shape as livecds on primary but are shipped as a oem disk image, where initial-setup is used to do final user configuration. pungi generates a install tree the same as it does for primary, we are creating pxe install trees only as u-boot does not understand isofs.


Benefit to Fedora

Enables fedora to embrace the emerging arm world. There is currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and newer devices are all arm based. Calxeda based servers are shipping today. We could look at having tablet spins in the future but that is currently outside the scope of this Change. we will be adopting and embracing the the future.

Scope

Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64 Build hardware already exists in phx2 and is configured to talk to koji.

  • Proposal owners: change the arches in koji, import the matching rawhide builds into koji. update release Engineering scripts to automatically build armhfp trees along with i386 and x86_64
  • Other developers: submit builds as normal, in the event of unexpected build failures talk to the arm team to help debug and fix issues
  • Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are the people proposing the Change.


  • Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji


Upgrade/compatibility impact

systems running Fedora 18 or 19 should be upgradeable in the same way as x86 systems are.


How To Test

there are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported arm system should work as it does today for ARM as a secondary arch.

User Experience

User experience does not change. The only difference will be the path in which they use to download files from on the mirrors.

Dependencies

There are no special depeendencies. Hardware in Phoenix is already installed, there is release engineering boxes for doing composing on, there is hardware available for QA use.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) if for some reason we fail horribly at migrating into primary we would go back to secondary, the fix would be removing armv7hl from the build arches by Release Engineering
  • Contingency deadline: Alpha
  • Blocks release? Yes

Documentation

Release Notes