(Initial version) |
No edit summary |
||
Line 24: | Line 24: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- 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 83: | Line 83: | ||
* Cockpit storage - this is an external tool which is provided to the user, however, thanks to the fact that web UI and Cockpit storage are based on the same technologies, we are able to integrate Cockpit Storage into the Anaconda web UI. '''Please note, that it is still an external tool and shouldn’t be taken as part of the installation workflow.''' We are trying to make this obvious in the UI. | * Cockpit storage - this is an external tool which is provided to the user, however, thanks to the fact that web UI and Cockpit storage are based on the same technologies, we are able to integrate Cockpit Storage into the Anaconda web UI. '''Please note, that it is still an external tool and shouldn’t be taken as part of the installation workflow.''' We are trying to make this obvious in the UI. | ||
** We have chosen the Cockpit Storage because it is using the same PatternFly and Cockpit frameworks as the web UI, so it has a consistent look and feel and allows us much seamless integration with Anaconda. Also Cockpit Storage can be used with remote HTTPS installations in the future. Users of Fedora might be familiar with this tool because it is already used in Cockpit, it is a stable and well maintained project. | ** We have chosen the Cockpit Storage because it is using the same PatternFly and Cockpit frameworks as the web UI, so it has a consistent look and feel and allows us much seamless integration with Anaconda. Also Cockpit Storage can be used with remote HTTPS installations in the future. Users of Fedora might be familiar with this tool because it is already used in Cockpit, it is a stable and well maintained project. | ||
** Cockpit storage does not support action planning which creates controversy around this approach. All the actions done in the Cockpit Storage are immediately applied to the disk. This is a drawback compared to the current GTK UI, however, the approach as explained above should be used as the secondary option when you are not satisfied with the Guided partitioning and only for advanced users. This shouldn't be taken as the main installation method nor part of the installation workflow. | ** Cockpit storage does not support action planning which creates controversy around this approach. All the actions done in the Cockpit Storage are immediately applied to the disk. This is a drawback compared to the current GTK UI, however, the approach as explained above should be used as the secondary option when you are not satisfied with the Guided partitioning and only for advanced users. This shouldn't be taken as the main installation method nor part of the installation workflow. | ||
Based on the feedback we have decided to implement these changes: | |||
https://discussion.fedoraproject.org/t/108995/58 | |||
== Feedback == | == Feedback == | ||
Line 98: | Line 102: | ||
** Reply: Reasons were already described above. Anaconda team size has reduced a lot recently and we are looking at ways to maintain less to be able to keep the project alive reasonably and not only for bug fixing. Implementing our own solution would take significant resources to implement and would increase maintenance costs. | ** Reply: Reasons were already described above. Anaconda team size has reduced a lot recently and we are looking at ways to maintain less to be able to keep the project alive reasonably and not only for bug fixing. Implementing our own solution would take significant resources to implement and would increase maintenance costs. | ||
A lot of feedback was received on https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995 | |||
== Benefit to Fedora == | == Benefit to Fedora == |
Revision as of 14:41, 5 September 2024
Anaconda Web UI partitioning
Summary
The Anaconda OS installer project needs to have a new approach for partitioning with the new web UI. This approach needs to be easy to control for users who don’t understand details of the Linux storage but still allows more complex requirements.
Owner
- Name: Jiri Konecny
- Email: jkonecny@redhat.com
Current status
- Targeted release: We would like to start discussion before proposing this to specific Fedora version.
- Last updated: 2024-09-05
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
This is separation of one topic from the Anaconda WebUI for Fedora Workstation by default change in Fedora. The storage part of the new installer UI was extracted here to start an open discussion of our solution, to collect feedback and get agreement with the proposed approach. Main reason for creating this change is to agree on a solution and to find feasibility for the next Fedora delivery.
With the current GTK UI of Anaconda we provide users three ways of creating partitioning.
- Automatic - select disks (optional encryption) and Anaconda will do everything else for you.
- If disks are not empty a pop-up will show, which allows you to select what partitions you want to remove or preserve to free up space for the automatic installation.
- Custom - select disks and then you will get to an advanced screen where you design your output partitioning. This is the top-bottom partitioning approach where you design your mount points but do not have to care about how the final goal is reached.
- Blivet-gui - select disks and then design your storage from the bottom (bottom-top approach) by creating a partition on it BTRFS etc…
- This solution was added later and its external tool integrated into Anaconda, not directly maintained by the Anaconda team.
However, with web UI we need to change this because technologies are different. When we are changing this, we would like to resolve old pains of the current approach. The current approach is great in being middle ground but in general, however, there are people who want to have something extra (top-bottom approach is not specific enough) but we also do not cover users, who don’t have much experience with Linux partitioning (use cases as reinstall my existing system). Another issue is that the Anaconda team size has reduced significantly from times when the GTK solution was created, so we are looking for solutions which are simple yet smart and easier to maintain and extend.
Our solution:
- Guided partitioning - this is a more powerful automatic partitioning where the user will select a goal and have additional customizations possible. The goal here is that most users should be covered by this guided experience.
- Currently our implementation has three possibilities:
- Reinstall all selected disks and remove everything that is on them.
- Install into a free space on selected disks.
- Use existing storage and assign mount points for the installed system.
- Good option for reusing the existing partitioning.
- Users can also create their partitioning ahead of time with any partitioning tool they prefer and use this option to just tell Anaconda how to use the partitioning.
- We will extend the existing set of possibilities with the following list:
- Reinstall existing system.
- Users will have a list of existing systems installed on disks and select which one they want to reinstall (remove existing system and install to the same space).
- Anaconda will replace root and should have a possibility to preserve /home with user data.
- Easy way to reclaim space from the existing disks and start installation to the free space.
- Similar approach to what we had on GTK UI.
- It is simple and should cover a lot of cases in a simple way.
- Based on the user feedback we would love to add more requested workflows.
- Reinstall existing system.
- Currently our implementation has three possibilities:
- Cockpit storage - this is an external tool which is provided to the user, however, thanks to the fact that web UI and Cockpit storage are based on the same technologies, we are able to integrate Cockpit Storage into the Anaconda web UI. Please note, that it is still an external tool and shouldn’t be taken as part of the installation workflow. We are trying to make this obvious in the UI.
- We have chosen the Cockpit Storage because it is using the same PatternFly and Cockpit frameworks as the web UI, so it has a consistent look and feel and allows us much seamless integration with Anaconda. Also Cockpit Storage can be used with remote HTTPS installations in the future. Users of Fedora might be familiar with this tool because it is already used in Cockpit, it is a stable and well maintained project.
- Cockpit storage does not support action planning which creates controversy around this approach. All the actions done in the Cockpit Storage are immediately applied to the disk. This is a drawback compared to the current GTK UI, however, the approach as explained above should be used as the secondary option when you are not satisfied with the Guided partitioning and only for advanced users. This shouldn't be taken as the main installation method nor part of the installation workflow.
Based on the feedback we have decided to implement these changes: https://discussion.fedoraproject.org/t/108995/58
Feedback
We unfortunately don’t have much feedback from the community yet, however, for that reason the FESCO decided in https://pagure.io/fesco/issue/3169 that we should have testing for feedback collection after Fedora 40 is released.
However, we were able to collect a bit of a feedback from FESCO members
- Cockpit storage is missing planning and immediate execution of actions feels unsafe.
- Reply: We worked hard on notifying users that this is the case and users could lose their data (which applies to any partitioning method). Also this tool should be used only by the advanced users and ideally only to a smaller number of them. The guided solution should be the preferred one.
- What other tools can we use than Cockpit Storage?
- Reply: To our knowledge there are no other tools for partitioning based on the same technologies as we are using for Cockpit Storage. Which is making the Cockpit Storage an obvious choice for us and enables us to also support this tool with remote HTTPS installations in the future.
- Why Anaconda won’t implement their own solution.
- Reply: Reasons were already described above. Anaconda team size has reduced a lot recently and we are looking at ways to maintain less to be able to keep the project alive reasonably and not only for bug fixing. Implementing our own solution would take significant resources to implement and would increase maintenance costs.
A lot of feedback was received on https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995
Benefit to Fedora
Anaconda GTK UI partitioning solution is quite complex but it also could be limiting to advanced users. Our new solutions should simplify the process of partitioning for Fedora users by selecting what they want to achieve instead of how to achieve and leave the rest on Anaconda. On the other hand we also allow users to use external partitioning tools if they prefer.
Thanks to the fact that the Cockpit Storage project is maintained by another team, the Anaconda team should have more capacity to focus on other goals and priorities. As the outcome of this, Anaconda team should have more capacity for feature work and bug fixing of issues for the Fedora users.
The biggest benefit is the new guided partitioning. This approach should simplify installation a lot and provide a powerful tool for users who don't bother about details but want to achieve a specific goal.
Scope
- Proposal owners:
- Anaconda team
- Cockpit team
- Other developers: Should not have impact out of the Fedora Workstation Live environment.
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives:
Upgrade/compatibility impact
This is a change to the installer of the system - no compatibility or upgrade issues are expected to happen.
How To Test
Download the latest Fedora Workstation ISO from Rawhide and start the installation. We already reached the Fedora QE team to set the test day for more comprehensive testing and feedback collection with more details.
Steps:
- Download the ISO image (https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/)
- Start a VM with this ISO image
- Run the installation
- Share your feedback and bugs to either https://bugzilla.redhat.com/ or https://discussion.fedoraproject.org/ (change proposal link after discussion thread is created).
- Bugs should be filed to Red Hat Bugzilla on the Anaconda component.
User Experience
New partitioning solution together with a new web UI which should simplify and improve user experience.
Dependencies
Cockpit and Cockpit storage packages.
Contingency Plan
- Contingency mechanism: Return back to the current GTK UI by changing packages to build the ISO.
- Contingency deadline: Beta freeze
- Blocks release? No, we can ship without the new web UI
Documentation
Documentation should be extended to guide users in how to create partitioning beforehand if that is their desire.
Release Notes
TBD