From Fedora Project Wiki
No edit summary
No edit summary
 
(48 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Build Fedora IoT using rpm-ostree unified core mode =
= Build Fedora IoT using rpm-ostree unified core =


{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
rpm-ostree upstream development is focusing on the "unified core" mode and the previous mode is being deprecated. Fedora IoT is currently building using the old mode and we've wanted to move over for a while. The main advantage of the unified core mode is that it is stricter and safer, while enabling some post processing steps to happen during or after the image build.
Upstream rpm-ostree development is now focused on "unified core" mode, with plans to deprecate the previous mode in the future. Fedora IoT is the last rpm-ostree based Fedora edition using this older, soon to be deprecated mode with SilverBlue and Kinoite making the change in Fedora 39. This change will align IoT with the other ostree-based editions in Fedora.


== Owner ==
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]], [[User:idiez| Irene Diez]]  
* Name: [[User:pwhalen| Paul Whalen]], [[User:idiez| Irene Diez]]  
* Email: <pwhalen@fedoraproject.org>, <>
* Email: pwhalen@fedoraproject.org, idiez@redhat.com


<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF40]]
<!-- 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 -->
Line 27: Line 20:
[[Category:SelfContainedChange]]
[[Category:SelfContainedChange]]


* Targeted release: [[Releases/40 | Fedora Linux 40 ]]  
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- 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  
Line 35: Line 28:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [<will be assigned by the Wrangler> devel thread]
* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/T4TMOSVB2P7ZVNMDJENHZTTKGEJ3TAL3/ Announced]
* FESCo issue: <will be assigned by the Wrangler>
* [https://discussion.fedoraproject.org/t/f40-change-proposal-build-fedora-iot-using-rpm-ostree-unified-core-self-contained/101959 Discussion thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3161 #3161]
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2263306 #2263306]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>


== Detailed Description ==
== Detailed Description ==
For more details about the difference between the two modes, you can read the upstream issue: https://github.com/coreos/rpm-ostree/issues/729. See also the history in https://pagure.io/workstation-ostree-config/issue/137.
To learn about the differences between unified core and the previous mode, please read the upstream [https://github.com/coreos/rpm-ostree/issues/729 issue]. The main advantage is that it is stricter and safer, while enabling some post processing steps to happen during or after the image build. In addition, unified core support is required for bootupd integration in Fedora IoT and to align with other rpm-ostree editions in Fedora.  


On top of the advantages listed above, we need unified core support to be able to add bootupd integration to Fedora IoT and to align with other ostree editions in Fedora.  
Related changes (already complete):
 
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd


== Feedback ==
== Feedback ==
Line 49: Line 46:


== Benefit to Fedora ==
== Benefit to Fedora ==
The old mode in rpm-ostree is not maintained anymore and less tested thus more prone to bugs. Moving to the new mode will unify IoT with that is used to build Fedora CoreOS and that receives a lot of testing. This will remove maintenance burden on the rpm-ostree project as they will thus be able to remove the old code. The new mode also makes composes work the same on the server side and the client side and makes them safer by more strictly confining scriptlets execution.
The previous mode in rpm-ostree is not maintained anymore, less tested and thus prone to bugs. Moving to unified core will align IoT with what is used to build Fedora CoreOS, SilverBlue and Kinoite as well as benefit from the additional testing those editions receive. Making the change in IoT should also reduce the maintenance burden from the rpm-ostree project as they will be able to remove the old code. Unified core makes composes work the same on the server side as the client side and makes them safer by more strictly confining scriptlet execution.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners: Testing with the new mode to ensure there are no regressions.
<!-- 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: N/A
 
* Release engineering: [https://pagure.io/releng/issue/11815 #11815]
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change)  
<!-- 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?-->
* Trademark approval: N/A
 
* Alignment with Community Initiatives: N/A
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- 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 rebuild required?  include a link to the releng issue.
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 
* Policies and guidelines: N/A (not needed for this Change) <!-- 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. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
 
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
 
* Alignment with Community Initiatives:  
<!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
Line 75: Line 60:


== How To Test ==
== How To Test ==
* Upgrade to Fedora 40 IoT Edition
* Upgrade to Fedora 40 IoT Edition or deploy a new installation.


== User Experience ==
== User Experience ==

Latest revision as of 09:12, 8 February 2024


Build Fedora IoT using rpm-ostree unified core

Summary

Upstream rpm-ostree development is now focused on "unified core" mode, with plans to deprecate the previous mode in the future. Fedora IoT is the last rpm-ostree based Fedora edition using this older, soon to be deprecated mode with SilverBlue and Kinoite making the change in Fedora 39. This change will align IoT with the other ostree-based editions in Fedora.

Owner

Current status

Detailed Description

To learn about the differences between unified core and the previous mode, please read the upstream issue. The main advantage is that it is stricter and safer, while enabling some post processing steps to happen during or after the image build. In addition, unified core support is required for bootupd integration in Fedora IoT and to align with other rpm-ostree editions in Fedora.

Related changes (already complete):

Feedback

Benefit to Fedora

The previous mode in rpm-ostree is not maintained anymore, less tested and thus prone to bugs. Moving to unified core will align IoT with what is used to build Fedora CoreOS, SilverBlue and Kinoite as well as benefit from the additional testing those editions receive. Making the change in IoT should also reduce the maintenance burden from the rpm-ostree project as they will be able to remove the old code. Unified core makes composes work the same on the server side as the client side and makes them safer by more strictly confining scriptlet execution.

Scope

  • Proposal owners: Testing with the new mode to ensure there are no regressions.
  • Other developers: N/A
  • Release engineering: #11815
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A
  • Alignment with Community Initiatives: N/A

Upgrade/compatibility impact

  • There will be no impact to end users, upgrades will work the same as previous releases

How To Test

  • Upgrade to Fedora 40 IoT Edition or deploy a new installation.

User Experience

  • There will be no impact to users.

Dependencies

N/A

Contingency Plan

  • Contingency mechanism: Revert to older non-unified core mode.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

Documentation

N/A (not a System Wide Change)

Release Notes

N/A

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Fedora_IoT_Unified_Core&oldid=700505"