< Changes
No edit summary |
No edit summary |
||
| 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 | * 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> | ||
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
- Name: Jiří Konečný
- Email: jkonecny@redhat.com
- Release notes ticket: #105
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.
- Release engineering: #7240
- List of deliverables: N/A
- 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