From Fedora Project Wiki
(First complete draft of this change.)
No edit summary
 
(11 intermediate revisions by 3 users not shown)
Line 34: Line 34:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: jkonecny@redhat.com
* Email: jkonecny@redhat.com
* 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/105 #105]
<!--- 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>
Line 54: Line 54:
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
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1537245 #1537245]


== Detailed Description ==
== Detailed Description ==
Line 61: Line 61:
to support its customization, extensibility and testability. It will be easier to monitor the installation, maintain an install class or an
to support its customization, extensibility and testability. It will be easier to monitor the installation, maintain an install class or an
addon, drop some modules or provide your own UI.
addon, drop some modules or provide your own UI.
This is just the first part of our move towards a modular (DBus) solution. The whole Anaconda logic will not be moved in F28 to modules at once, instead small parts will be moved to the DBUS modules incrementally. This process will start with simple non-critical parts (e.g. reading, parsing and getting kickstart data for modules) and progressively move to more complicated and critical parts (e.g. running installation tasks like package installation), while making sure the installation keeps working as expected.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 66: Line 68:
* Anaconda addons have stable API to work with.
* Anaconda addons have stable API to work with.
* Users can create their own UI or even UI less installation.
* Users can create their own UI or even UI less installation.
* Enables running the UI as a non-root user (a requirement for running Anaconda GUI natively on Wayland in the future).
* Anaconda modules can be enabled and disabled or even not present in the installation environment.
* Anaconda modules can be enabled and disabled or even not present in the installation environment.
* Better test-ability of Anaconda.
* Better test-ability of Anaconda.
Line 75: Line 78:
<!-- 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?-->
** Split Anaconda to modules with DBus API.
** Split Anaconda to modules with DBus API.
** Old UI must be rewritten to use new DBus API.
** Old UI must be modified to use new DBus API.


* Other developers: <!-- N/A (not a System Wide Change) --> <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- N/A (not a System Wide Change) --> <!-- REQUIRED FOR SYSTEM WIDE 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?-->
<!-- 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?-->
** Thanks to the nature of how addons work right now, we need cooperation during the transition period of addon developers.
** Thanks to the nature of how addons work right now, we need a cooperation from the Anaconda addon developers.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/7240 #7240] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED 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.  
<!-- 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 -->
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 -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines:  
** No change should be required <!-- 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 97: Line 101:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
This change should be backward compatible. No user intervention will be required.


== How To Test ==
== How To Test ==
Line 115: Line 119:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Testing should stay the same for Fedora QA. Existing tests should be working all the time.


== User Experience ==
== User Experience ==
Line 126: Line 130:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Only addon packages may require some changes in their code.


== 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: Fallback to the old (non-modular) solution will be still available during development. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism:  
** New rawhide fallback branch will be created on the day of switching first component to the new DBus modular solution.
** All critical patches (blockers, freeze exceptions...) will be backported to this fallback branch.
** This special branch can be used if contingency plan is needed.
 
<!-- 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: Final freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: A week before final freeze  <!-- 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? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 155: Line 163:
TODO
TODO


[[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 -->
Line 162: Line 170:


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

Latest revision as of 15:03, 2 March 2018


Anaconda modularization

Summary

Anaconda installer will be split into several modules that will communicate over DBus using stable API.

Owner

Current status

Detailed Description

Anaconda will be split into several modules that will communicate over DBus. The goal is to introduce a stable way to interact with Anaconda to support its customization, extensibility and testability. It will be easier to monitor the installation, maintain an install class or an addon, drop some modules or provide your own UI.

This is just the first part of our move towards a modular (DBus) solution. The whole Anaconda logic will not be moved in F28 to modules at once, instead small parts will be moved to the DBUS modules incrementally. This process will start with simple non-critical parts (e.g. reading, parsing and getting kickstart data for modules) and progressively move to more complicated and critical parts (e.g. running installation tasks like package installation), while making sure the installation keeps working as expected.

Benefit to Fedora

  • Anaconda addons have stable API to work with.
  • Users can create their own UI or even UI less installation.
  • Enables running the UI as a non-root user (a requirement for running Anaconda GUI natively on Wayland in the future).
  • Anaconda modules can be enabled and disabled or even not present in the installation environment.
  • Better test-ability of Anaconda.


Scope

  • Proposal owners:
    • Split Anaconda to modules with DBus API.
    • Old UI must be modified to use new DBus API.
  • Other developers:
    • Thanks to the nature of how addons work right now, we need a cooperation from the Anaconda addon developers.
  • Policies and guidelines:
    • No change should be required
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change should be backward compatible. No user intervention will be required.

How To Test

Testing should stay the same for Fedora QA. Existing tests should be working all the time.

User Experience

User experience should be consistent with the older releases.

Dependencies

Only addon packages may require some changes in their code.

Contingency Plan

  • Contingency mechanism:
    • New rawhide fallback branch will be created on the day of switching first component to the new DBus modular solution.
    • All critical patches (blockers, freeze exceptions...) will be backported to this fallback branch.
    • This special branch can be used if contingency plan is needed.
  • Contingency deadline: A week before final freeze
  • Blocks release? No

Documentation

https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/

Most of the articles here: https://rhinstaller.wordpress.com

Release Notes

TODO

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