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.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.
So, this is just the f41 change trying again for f42.
The reason it was delayed was "we don't have time required to get the project into shape which we would like to deliver to users based on the feedback we were able to collect"
I assume that things are now in a shape to deliver to users?
If so, +1
I did some testing of the new WebUI installer and the F41 installer and Ubuntu Subiquity for comparison. The overall conclusion is that the new installer is limited and at this point seems rather buggy. There doesn't seem to be any clear improvement in functionality over the previous installer. But we clearly regress on an important part, i.e. the prepare-and-execute approach for simple and medium-complexity installs (https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995/65).
The main reasons that are cited for the rework is the need to support installs over HTTP, a reduced team size, and the ability to use cockpit backend. I find those unconvincing. if the team is too small to keep supporting an existing working design, then almost certainly it'll struggle to implement a new design with new technology and improve that until all the major bugs have been ironed out. I also don't appreciate the need for HTTP. In my world, people do local installs where they care about the existing stuff on disk and do local tweaks, so the existing tooling in Anaconda that allows that is important, or they do remote installs using prepared images and automatic deployments, and the interactive installer doesn't matter. And the cockpit backend is OK for some basic administrative tasks, but it isn't intended for setting up an installation and most likely will never be good for that.
-1. We clearly have the alternative of keeping the existing Anaconda code and limping along until something better becomes an option. That may even be the WebUI installer. But at this point it is too early to predict when it'll reach such a stage. Thus, I think we should keep the current Anaconda until an alternative is mostly ready and we can make an informed decision, instead of promising to switch to something that doesn't exist yet.
I'm mostly in the same boat as well. -1
As a side note, I think the refactoring done to make Anaconda support the Cockpit frontend could be interesting for alternative frontends to be made. I'm aware of at least someone contributing support for Anaconda as a backend to the elementary OS installer UI: https://github.com/elementary/installer/pull/738
If it's possible, I'd love to see the Anaconda bridge API documented so it could become possible to explore alternatives to the current GTK UI without having to rewrite the world to do it.
But at this point it is too early to predict when it'll reach such a stage. Thus, I think we should keep the current Anaconda until an alternative is mostly ready and we can make an informed decision, instead of promising to switch to something that doesn't exist yet.
I'm a bit worried about this logic.
It's clearly more difficult for the - admittedly substantially size-reduced - anaconda team to continue working on webUI if there's no clarity about whether FESCo will ever be minded to accept it. It's probably only practical for them to work on it on the basis that it definitely will become the sole installer UI for Fedora and RHEL one day.
I'm not sure it's a good idea for FESCo to be effectively claiming the position of making permanent design decisions for the whole RH ecosystem, which is what this sounds a lot like. In the end, the anaconda team are the folks who are getting paid to build an installer for all of us. FESCo telling them how to design the installer feels a bit like a tail wagging a dog, to me. At the least it seems to come with a substantial risk of the only folks paid to work on this telling Fedora to pound sand, cutting work on the existing UI, and putting the new UI directly in RHEL instead (to be extremely clear, I have absolutely no indication that this has been remotely considered, I'm just foreseeing it as a risk), and then where are we? Does Fedora try and get resources from...somewhere...to maintain the old UI? Build a different new UI? Use a different installer? Even if that works, now we have further increased the delta between Fedora and the rest of the RH-verse, which isn't great for anyone.
I really feel like, if we're not going to talk in terms like "we recognize this redesign is coming but we have specific practical concerns on specific timelines", but instead make broader pronouncements without clear bounds or timelines, those decisions need to be made in concert with other stakeholders (RHEL and CentOS folks), not just in FESCo.
I think we've been fairly clear on the issues with the web UI. From our point of view in FESCo, we have to accept that whatever change we make also affects our competitiveness in the larger Linux distribution space. While it's true our current GTK based UI is somewhat maligned, it's a big problem that the new UI regresses on concepts that we introduced over a decade ago.
Honestly, I don't want to be on the receiving end of users being angry at us because of our partitioner being so bad. That is the single biggest reason why I voted against it. The Cockpit partitioner is a foot-gun waiting to happen. I could hand-wave away all the rest of the issues if it weren't for that one.
And in a practical sense, the GTK UI has to stick around at least for the next ten years because it's shipping in RHEL 10.
Telling us we need to accept this because Red Hat doesn't want to invest in resolving the community feedback (e.g. grow the team and commit to developing it properly) is not great either. I have no idea what's going on inside of Red Hat, but I wonder if anybody looked at what their competitors are doing? Both Canonical and SUSE are also modernizing their installers: SUSE with Agama and Ubuntu with the new Ubuntu installer. SUSE's is the more radical of the two: they've stripped out a lot of the extra stuff from YaST and made a single-purpose installer. I've previewed the work on Agama by the folks at SUSE, and it's much more in line with what I expect from the installer. And in fact, our Anaconda has these capabilities, they're just not plumbed into the frontend.
If our new installer frontend was bringing us more of what we have in our existing GTK one, I'd be much happier about it, and I think the rest of FESCo would be too.
Frankly, I suspect what's going on in Red Hat is that we have decided investing money into further development of the OS installer isn't going to produce much in the way of returns, which is why the team working on it keeps shrinking.
Downstream maintenance of the installer that shipped in RHEL 10 isn't really relevant to forward-looking work in Fedora, though. oldUI stuck around in RHEL for years after we moved to newUI in Fedora in F18, but we didn't keep maintaining oldUI in Fedora.
While I can - to some degree - rationalize both points of view here, I just don't want us (as in, the Fedora Project) to get into a situation where we need to "take it or leave it", i.e. either take the new installer UI, with all the new bugs, regressions, and loss of features (at least that's what it currently looks like), or ending up needing to investigate other options ~somehow~. This feels more and more like were getting "an offer that we cannot refuse", and I don't think that's a good situation to be in.
It's clearly more difficult for the - admittedly substantially size-reduced - anaconda team to continue working on webUI if there's no clarity about whether FESCo will ever be minded to accept it. It's probably only practical for them to work on it on the basis that it definitely will become the sole installer UI for Fedora and RHEL one day. I'm not sure it's a good idea for FESCo to be effectively claiming the position of making permanent design decisions for the whole RH ecosystem, which is what this sounds a lot like.
I'm not sure it's a good idea for FESCo to be effectively claiming the position of making permanent design decisions for the whole RH ecosystem, which is what this sounds a lot like.
Those two statements highlight the problem. We're being asked to vote to promise to switch to a project that right now is in early stages and for which there are significant doubts about the selection of priorities. I'm not trying to "make permanent design decisions for the whole RH ecosystem", but instead I'm trying to decide whether it's in the benefit of Fedora to promise to switch. And switching to an implementation which is a rewrite with functional regressions is clearly not beneficial for Fedora.
I understand that RH priorities have shifted and the team behind Anaconda doesn't feel like that they can both satisfy the requests from RH and what Fedora folks. But that doesn't mean that we have to unquestioningly accept the RH design choices. Like with any other upstream, the fundamental role of the distro is to push back on upstream changes that are not in the interest of the users.
I won't comment on what is written here. I just want to point you to the fact that current GTK UI is written in GTK3 which might be an issue for the Anaconda team might be "forced" to resolve.
However, I would like to know why FESCO didn't accepted / comment on our list of our proposed improvements: https://discussion.fedoraproject.org/t/108995/58
This was created to get some level of expectations from you. Because on-one was complaining it looked like you are fine with that? Could you please give us comment on that?
The current way of development is quite problematic for us. We are working on our best believe to fix project based on your complains with no requirement list. Last time this request was rejected with a note that someone from FESCO will make sure there will be test day after F41 release and we will finally got our feedback and requirements list. F41 is not yet released and we are again getting rejected.
Currently, our development is blind and we are doing our best without knowing how the next round will go. If you want to get this working then we need your collaboration (-1 is not enough really).
Also please don't make this issue political one. Red Hat vs. Fedora, it is just wrong from my perspective.
Everyone should try to get the best product which is maintainable. That is the goal here.
Maybe I'm mistaken but isn't 100% CC deadline in Feb next year? Why is the voting happening on not full feature set (last feature is planned during this month) product? Also taking bugs into account 4 months before deadline seems quite soon, isn't it?
I would like to know why FESCO didn't accepted / comment on our list of our proposed improvements
I cannot speak for everyone on FESCo, but speaking for myself, I've provided quite a bit of feedback in the past that still remains relevant because the situation hasn't changed much. "Add reclaim space dialog" would restore some functionality that was available previously. It sounds reasonable, but is not implemented yet. "Make Cockpit Storage less visible option for partitioning" is, as stated many times before, just papering over the significant loss of functionality. Hiding this under some obscure menu just makes the installer harder to use, it doesn't resolve the fundamental problem. "Nice to have things" — nice incremental improvements, not implemented yet.
Maybe I'm mistaken but isn't 100% CC deadline in Feb next year?
Yes. It is a good question why vote -1 now. The Change proposal was made now and the options are to accept it or not and this forces our hand. If we accept, we implicitly promise to accept the work that'll be done. For many Change proposals, we do that and I think this is reasonable to vote on yet-to-be-implemented changes, if some requirements are met: the benefits and design must be clear, and the work needed must be reasonable to finish OR the design must be such that a partial implementation is not a problem. In case of the installer, we're talking about a switch from a working solution to a different implementation, and it seems that none of those requirements are met.
Of course. That isn't the intent. Nevertheless, we are in a situation where various Fedora contributors are saying that the choices are being made are not a good fit for Fedora. It seems that the situation is a result of RH internal realignments and priorities. Discussing this openly is the first step towards figuring out what is the best path forward for Fedora.
I would like to know why FESCO didn't accepted / comment on our list of our proposed improvements I cannot speak for everyone on FESCo, but speaking for myself, I've provided quite a bit of feedback in the past that still remains relevant because the situation hasn't changed much. "Add reclaim space dialog" would restore some functionality that was available previously. It sounds reasonable, but is not implemented yet.
I cannot speak for everyone on FESCo, but speaking for myself, I've provided quite a bit of feedback in the past that still remains relevant because the situation hasn't changed much. "Add reclaim space dialog" would restore some functionality that was available previously. It sounds reasonable, but is not implemented yet.
I'm confused by what you are saying because it is already delivered:
<img alt="Screenshot_Test-live_2024-10-04_153936.png" src="/fesco/issue/raw/files/94cd5bf0e02a791e5303951e29236e3338ff0ccb4cbb58d11f6637d55c67888f-Screenshot_Test-live_2024-10-04_153936.png" />
Is something missing in this implementation to you? It is basically the same what we have in the GTK UI right now.
"Make Cockpit Storage less visible option for partitioning" is, as stated many times before, just papering over the significant loss of functionality. Hiding this under some obscure menu just makes the installer harder to use, it doesn't resolve the fundamental problem. "Nice to have things" — nice incremental improvements, not implemented yet.
This is not telling us requirements. As explained multiple times we don't want to introduce new Custom Storage solution. Instead we enabled Reclaim space dialog and we are working on /home reuse workflow. That should be implemented during this month.
https://github.com/rhinstaller/anaconda/pull/5814 https://github.com/rhinstaller/anaconda-webui/pull/424
This is our step forward to be able to satisfy people requirements which is now resolved by the Custom partitioning. It was already discussed. Am I understand it correctly that this is not enough? If yes, than please share with me what is enough?
Maybe I'm mistaken but isn't 100% CC deadline in Feb next year? Yes. It is a good question why vote -1 now. The Change proposal was made now and the options are to accept it or not and this forces our hand. If we accept, we implicitly promise to accept the work that'll be done. For many Change proposals, we do that and I think this is reasonable to vote on yet-to-be-implemented changes, if some requirements are met: the benefits and design must be clear, and the work needed must be reasonable to finish OR the design must be such that a partial implementation is not a problem. In case of the installer, we're talking about a switch from a working solution to a different implementation, and it seems that none of those requirements are met.
Do I understand it correctly that if I would file this change last minute I will be in the better situation? Why are you forced to vote now?
Why are you forced to vote now?
We do not have to vote right now. If you ask us to hold off, we can and will hold off.
Why are you forced to vote now? We do not have to vote right now. If you ask us to hold off, we can and will hold off.
In that case, please hold off until the test days which we promised. That should happen after we have last feature implemented.
And switching to an implementation which is a rewrite with functional regressions is clearly not beneficial for Fedora.
Is it not, though? We do this all the time. We took systemd when it was, practically speaking, "a rewrite with functional regressions". We took the last anaconda newUI when it certainly was that. We take major updates to GNOME and KDE without FESCo nitpicking their design decisions and arguing about specific "functional regressions". It's always been understood that part of Fedora's job is to take new things quite early to help work out the kinks in them; I don't understand why we suddenly seem to be applying a higher standard to this installer rewrite.
Last go-round with the installer we were probably a bit too permissive (I checked, the previous newUI feature got accepted on the nod in a five minute discussion), and we should learn from that. But I think the lesson is more "we need to have a solid and realistic understanding of the tradeoffs in the rewrite and the timelines involved in bringing it to acceptable quality". To me some of the feedback here feels like we're rebounding too far in the other direction.
This was a long time ago, but when systemd was being enabled, it had many many rough edges, but it was already clearly superior in functionality to previous tools. The crucial part was that is was based on a good design, and the implementation shortcomings were just a matter of some programming effort. Anaconda newUI was also reviewed as a very promising thing. I don't see the webUI rewrite like that.
(And for KDE and GNOME, if there was a major rewrite that was a regression in functionality, I'm pretty sure we'd reject it. For example, both GNOME and KDE try to provide a web browser and other tools which we don't particularly like and just install firefox instead.)
we need to have a solid and realistic understanding of the tradeoffs in the rewrite and the timelines involved in bringing it to acceptable quality
Yes. Exactly. We're still beating the horse of queue-and-execute, without much progress. So at this time it's very hard to say when this acceptable quality level might be met.
This is a bad argument, as both GNOME 3.0 and KDE 4.0 were atrociously bad regressions from their predecessors that caused a lot of bad will in those projects for years. Both were allowed straight into Fedora.
Both projects have long since recovered from these disasters, but let's not pretend that they were anything else.
we need to have a solid and realistic understanding of the tradeoffs in the rewrite and the timelines involved in bringing it to acceptable quality Yes. Exactly. We're still beating the horse of queue-and-execute, without much progress. So at this time it's very hard to say when this acceptable quality level might be met.
For what it's worth, I had several conversations with the Anaconda WebUI folks about queue-and-execute concerns (both on Discussion and the merge requests where it was being actually designed). My personal view is this:
A question for @jkonecny: how hard would it be to make the predesigned "guided" partitioning setups template-able? Could we design it so that it would be easy for interested parties to add a new "standard" setup for the next Fedora release by sending a simple JSON/YAML/whatever merge request upstream?
(And for KDE and GNOME, if there was a major rewrite that was a regression in functionality, I'm pretty sure we'd reject it. For example, both GNOME and KDE try to provide a web browser and other tools which we don't particularly like and just install firefox instead.) This is a bad argument, as both GNOME 4.0 and KDE 3.0 were atrociously bad regressions from their predecessors that caused a lot of bad will in those projects for years. Both were allowed straight into Fedora. Both projects have long since recovered from these disasters, but let's not pretend that they were anything else.
This is a bad argument, as both GNOME 4.0 and KDE 3.0 were atrociously bad regressions from their predecessors that caused a lot of bad will in those projects for years. Both were allowed straight into Fedora.
We also suffered a lot for that, to the point that several long-time Fedorans (like myself) are seriously paranoid to never repeat that ever again. By one measure, we lost half our userbase from GNOME 3.0. No way we want to repeat that.
We would have brainstorm about it before saying anything for sure. However, I'm pretty sure that we don't want to introduce a new JSON/YAML etc... format to what exists already. What may be doable is predefined kickstart solution which you can select as one of the options but that is probably not what you are asking for.
Could you please explain what would be the goal of these templates? Ideally an example.
A question for @jkonecny: how hard would it be to make the predesigned "guided" partitioning setups template-able? Could we design it so that it would be easy for interested parties to add a new "standard" setup for the next Fedora release by sending a simple JSON/YAML/whatever merge request upstream? We would have brainstorm about it before saying anything for sure. However, I'm pretty sure that we don't want to introduce a new JSON/YAML etc... format to what exists already. What may be doable is predefined kickstart solution which you can select as one of the options but that is probably not what you are asking for. Could you please explain what would be the goal of these templates? Ideally an example.
Never mind; I remembered over the weekend that "incomplete" kickstarts are already usable. People can pass their own partitioning config that way and then do anything else with the UI. So what I was thinking about is basically already covered.
Let's discuss this during a meeting.
Metadata Update from @zbyszek: - Issue tagged with: meeting
We discussed this during today's meeting. No conclusion was reached, except for:
We'll reach out to Anaconda folks to ask when they could join the FESCO meeting. Let's punt until then.
@jkonecny When would work for you?
When and where are the FESCO meetings happening? I'm happy to join but I remember that I had hard time to find this information in the past...
We have our meetings in #meeting:fedoraproject.org Matrix room.
#meeting:fedoraproject.org
... Tuesdays at 17:00 UTC in #meeting:fedoraproject.org on Matrix.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-10-15 17:00 UTC'
It's not best time for me but I should be able to get there.
(And for KDE and GNOME, if there was a major rewrite that was a regression in functionality, I'm pretty sure we'd reject it. For example, both GNOME and KDE try to provide a web browser and other tools which we don't particularly like and just install firefox instead.) This is a bad argument, as both GNOME 3.0 and KDE 4.0 were atrociously bad regressions from their predecessors that caused a lot of bad will in those projects for years. Both were allowed straight into Fedora. Both projects have long since recovered from these disasters, but let's not pretend that they were anything else. we need to have a solid and realistic understanding of the tradeoffs in the rewrite and the timelines involved in bringing it to acceptable quality Yes. Exactly. We're still beating the horse of queue-and-execute, without much progress. So at this time it's very hard to say when this acceptable quality level might be met. For what it's worth, I had several conversations with the Anaconda WebUI folks about queue-and-execute concerns (both on Discussion and the merge requests where it was being actually designed). My personal view is this: Yes, it's a regression in the custom flow that we will get flack for in the media. If we include this, it will have to come with a carefully considered strategy on how to communicate it. It may not be as much of a real-world problem if the "guided" partitioning is properly designed to handle the most important use-cases. ("Wipe and use the whole disk in the recommended format" and "Use existing partitions that were created before starting or from a previous install, selecting only mount points" being the two most likely ones for an interactive install). I'm actually open to not include the custom partitioning at all as part of the WebUI feature (or at least to make it require a kernel command-line argument to expose it). Let's be honest: complex partitioning deployments are far more likely to use a kickstart. My primary hesitation around this is that there's a reasonable workflow today of "Do an interactive install once, take the generated kickstart file and tweak it, then use that KS file on a hundred other machines". That workflow would require adaptation to enable the custom configuration if needed. A question for @jkonecny: how hard would it be to make the predesigned "guided" partitioning setups template-able? Could we design it so that it would be easy for interested parties to add a new "standard" setup for the next Fedora release by sending a simple JSON/YAML/whatever merge request upstream?
While we're talking about use cases - one reason I always use custom partitioning is I override the Fedora default of not having a dedicated swap partition so I can hibernate my systems easier. If this is exposed as an option, I wouldn't have to use custom partitioning; if custom partitioning is hidden behind a kernel cmdline flag, that's fine, but if it's disabled completely this would be... problematic.
one reason I always use custom partitioning is I override the Fedora default of not having a dedicated swap partition so I can hibernate my systems easier. If this is exposed as an option, I wouldn't have to use custom partitioning.
I do the same.
[deleted. pagure wound not allow me to delete my own comment
For the repair system installation part, is it possible to back up /etc too as user config files reside there. We could create a oldetc sub volume to hold them or copy them over to ~/oldetc
I don't think that is a good idea. Not many users are able to understand what is in the /etc and these files might not be even compatible with the new system. I think this could lead into people breaking their systems by using the backup as it is.
good point. also it it possible to also have it work with opensuse? they have a simmilar BRTFS layout https://en.opensuse.org/SDB:BTRFS#Default_Subvolumes , it would allow them to try a fedora system without too much hassle
Might take this discussion back to https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995 ?
I'm dropping the meeting tag for now because we've deferred this twice:
FESCo meeting on 2024-10-15:
AGREED: Wait for the Anaconda team to deliver missing functionality and finish blog post / video describing current state. Then have this discussion again. (+6, 0, -0) (@sgallagh:fedora.im, 17:56:32)
FESCo meeting on 2024-10-22:
AGREED: We will still wait for the Anaconda team to deliver missing functionality and finish blog post / video describing current state. Then we will have this discussion again. This time, this will be recorded in the ticket. :) (@conan_kudo:matrix.org, 17:06:56)
Metadata Update from @jistone: - Issue untagged with: meeting
Hi, just an update that our Test Days will take place next week: https://fedoramagazine.org/test-week-contributors-for-anaconda-web-ui-installer-for-fedora-workstation/
We also released article to show current status and Web UI in more detail: https://fedoramagazine.org/anaconda-installer-redesign/
@jkonecny Would you mind putting together a summary of the feedback from the Test Days for FESCo to review?
I'm planning to do that. We just need some time to go through the list and set priorities etc.
I would like to also propose it the to FESCO meeting. But first give us a few days for processing.
Sorry for the delay, here is our summary.
This is the summary of the Tests Days together with our insights for the current Anaconda web UI status:
Reported bugs
About the feedback
Our summary, the web UI currently improved a lot
Another points
Resources
I would like to propose this topic for next meeting to discuss and ideally decide about the F42 GO/NO-GO
@jkonecny, I'm putting it on the agenda for the next meeting.
FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-12-03 17:00 UTC'
This was discussed during the meeting today: AGREED: APPROVED (+6, 1, 0)
Metadata Update from @zbyszek: - Issue untagged with: meeting - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.