Detecting language using up to the first 30 seconds. Use `--language` to specify the language Detected language: English [00:00.000 --> 00:11.200] Hello. Welcome to my talk about building a web UI for the Fedora installer. So my name [00:11.200 --> 00:18.600] is Martin Coleman, and I work in the team that's building the Anaconda installer used [00:18.600 --> 00:27.360] by Fedora, REL, CentOS, and REL distributions. First, I would like to talk a bit about, like, [00:27.360 --> 00:34.040] why we decided to actually build a web UI for our installer. And, yeah, first, like, [00:34.040 --> 00:39.880] very, very shortly about, like, the Fedora installer project. Yeah, the name of it is [00:39.880 --> 00:45.800] Anaconda, which is very confusing for some people doing Python in the scientific domain, [00:45.800 --> 00:52.080] because there is a very similar project in that it's like a Python thing, but it's called [00:52.080 --> 00:58.440] the same SV, but I think we are older. So, anyway, right now we have a GTK3 UI for the [00:58.440 --> 01:06.040] installer. We have a text-based UI. It's also possible to fully automate the installation. [01:06.040 --> 01:12.760] We have things like add-on support, and, yeah, we are used, as I mentioned, by Fedora, REL, [01:12.760 --> 01:19.400] CentOS, and others. This talk is basically concerning only the graphical user interface. [01:19.400 --> 01:25.280] We don't expect to have any changes for the text-based interface and the kickstart-based [01:25.280 --> 01:34.160] automation in the context of the web UI. So, why did we actually choose to do something [01:34.160 --> 01:39.720] about the current graphical interface, and why did we choose to start working on a web [01:39.720 --> 01:49.640] UI? So, one of the points is that the current GTK interface comes from the year 2013, kind [01:49.640 --> 01:56.920] of looks like early GNOME 3 by coincidence. Maybe it was built at the same time, basically. [01:56.920 --> 02:02.400] And over time, we added new features. We fixed bugs. We adapted to various Fedora changes, [02:02.400 --> 02:10.480] for example. And the stuff kind of got bolted on. Not always it was possible to change the [02:10.480 --> 02:17.960] UI. So, in some cases, it's getting a bit clunky already. Another issue is that some [02:17.960 --> 02:26.760] of the technology we built it on is getting a bit old right now. GTK3 is not that old [02:26.760 --> 02:33.400] at the moment, but already you have GTK4. Eventually, we would have to port it. One [02:33.400 --> 02:39.280] of the issues is, for example, that the Fedora installation image. The Fedora project tries [02:39.280 --> 02:46.400] to have minimal dependencies of applications. So, like, over time, you want to have, like, [02:46.400 --> 02:52.080] the minimal amount of libraries. So, we would have to quite possibly migrate to keep the [02:52.080 --> 02:58.120] image sizes small. That's one of the reasons. We also still run on top of X. There is even [02:58.120 --> 03:02.160] some hard dependency right now on keyboard switching during the installation. So, this [03:02.160 --> 03:08.360] is something we would have to address anyway. The remote access to a graphical installation [03:08.360 --> 03:17.560] right now is not the best. It's based on VNC. So, it's unsecure. It's not very efficient. [03:17.560 --> 03:23.280] It requires you to have a graphical system running on the host that you are installing. [03:23.280 --> 03:27.600] And you need a special application that might not be available that users might need to [03:27.600 --> 03:35.000] install. So, that's one of the issues. And also, I'm not saying it's not possible to [03:35.000 --> 03:39.800] test GTK3 interfaces, but basically, it's not that simple. And we don't really have [03:39.800 --> 03:45.720] any unit test coverage. Like, there are people from, for example, the Fedora QA community [03:45.720 --> 03:51.760] that do test Anaconda. But what they are using is basically a screenshot or graphical bitmap [03:51.760 --> 04:00.280] based testing right now. So, this is something that could be improved. And also, what we [04:00.280 --> 04:07.200] have seen in the past years is that there seems to be a clear trend towards using Web [04:07.200 --> 04:12.720] UIs for system management. Some of you might still remember some of the system config tools [04:12.720 --> 04:20.280] used on Fedora and CentOS and Trell that used to be available to configure stuff like services, [04:20.280 --> 04:25.640] networking, firewalls. All of these, over time, effectively became cockpit plugins for [04:25.640 --> 04:31.520] the cockpit web console. So, this seems to be the trend overall for system management [04:31.520 --> 04:42.520] as far as we can tell. So, what we kind of found out, there are some benefits of doing [04:42.520 --> 04:48.360] something about the current UI situation and doing something about it with a web technology [04:48.360 --> 04:56.160] based UI. So, while we are at it, we can address some of the UX issues we have right now because [04:56.160 --> 05:02.000] it's effectively a fresh start right now. It's easier to achieve a consistency because, [05:02.000 --> 05:07.120] yeah, you are building the whole thing. So, you can make sure that it's, since it feels [05:07.120 --> 05:13.920] similar, it's using the same concepts, the same workflows for everything, hopefully. [05:13.920 --> 05:22.560] Also another thing is that given the proliferation of Web UIs everywhere, basically, there seems [05:22.560 --> 05:29.320] to be much bigger community of users, of developers of these technologies. And there is overall [05:29.320 --> 05:36.320] more documentation, there is even more resources for non-developer roles like UX designers [05:36.320 --> 05:47.480] or usability testing projects. And this seems to be, unfortunately, quite lacking in many [05:47.480 --> 05:55.240] native GUI libraries right now in comparison to the web technologies. And also, like one [05:55.240 --> 06:03.840] quite big point for it is that using a Web UI, just to be specific, we are going to use [06:03.840 --> 06:10.160] the Web UI both locally and remotely. So, we want to run it for the local graphical [06:10.160 --> 06:16.000] session, if any, but also it makes it much, much easier to access the installation remotely. [06:16.000 --> 06:24.000] So, for any headless installations, it should be much easier for the users using the installer [06:24.000 --> 06:30.640] to connect securely and much more efficiently to the host that is being installed. Also, [06:30.640 --> 06:36.040] the host doesn't have to contain any graphical dependencies, effectively, because all the [06:36.040 --> 06:40.760] rendering is happening on the client. So, the installation image could be much smaller. [06:40.760 --> 06:46.200] And also, the installation time resource requirements could be much, much smaller. That could be [06:46.200 --> 06:53.440] an issue for stuff like Raspberry Pis or some IoT SBCs, which are perfectly fine for the [06:53.440 --> 06:58.640] tasks you will be using them. But if you try to do a graphical installation on them, varying [06:58.640 --> 07:04.080] like possible issues with drivers, it might need much more resources to just install, [07:04.080 --> 07:09.280] to bring up the graphical interface, then it will be using for its lifetime of doing [07:09.280 --> 07:16.120] some useful work. So, let's talk a bit about the technical [07:16.120 --> 07:23.160] details of the tools that we are using to build the UI for the third-line installer [07:23.160 --> 07:30.400] right now. So, this is the overall architecture. The install is already modular. In that, [07:30.400 --> 07:38.400] it has a Python backend, which has a D-Bus interface. Then we are using Cockpit to provide [07:38.400 --> 07:46.560] us a bridge between D-Bus and the web application, which itself is then written with ReactJS [07:46.560 --> 07:54.200] for the logic and pattern fly for the WebUI widget. The current Anaconda with the GTK [07:54.200 --> 08:00.680] 3UI with the text UI, and even with the Kickstart support, is actually using the same Python [08:00.680 --> 08:08.520] backend, and even the GTK 3UI already is communicating with the backend via D-Bus. So, this makes [08:08.520 --> 08:15.680] it possible for us to right now work in parallel, that we are building the WebUI next to these [08:15.680 --> 08:23.640] other UI's right now. Just instead of, like, directly calling D-Bus, you have pattern fly [08:23.640 --> 08:32.080] widgets React talking via D-Bus, calling D-Bus calls from the backend. This is very similar [08:32.080 --> 08:38.480] to Cockpit plugins in general. Usually, you have the networking screen in Cockpit, for [08:38.480 --> 08:45.280] example, and what it does, it's talking to network manager via this bridge. It's doing [08:45.280 --> 08:51.400] D-Bus calls from D-Bus. That's basically the idea of Cockpit, and we are reusing this for [08:51.400 --> 09:02.120] our project. Yeah, so, as I've already mentioned, it's not about another UI that you can remotely [09:02.120 --> 09:08.880] access while keeping the current graphical interface next to this. Like, eventually, [09:08.880 --> 09:14.320] once we cover all the necessary functionality for the given project or product, it should [09:14.320 --> 09:18.240] replace the current graphical interface. But right now, it's being developed next to [09:18.240 --> 09:24.480] it, and thanks to the module backend, thanks to the D-Bus interface, it's not that hard [09:24.480 --> 09:35.800] to do it. Also, one more thing that we found very, very useful is the Cockpit test framework. [09:35.800 --> 09:41.080] This is addressing the issue I've mentioned previously about no unit tests for the graphical [09:41.080 --> 09:46.400] interface. This is something that has been developed for the Cockpit project itself, [09:46.400 --> 09:53.960] which directly maintains a lot of the screens you will see when you install Fedora or CentOS [09:53.960 --> 10:00.400] or some such distribution and enable Cockpit. But there are also many community-maintained [10:00.400 --> 10:07.160] outside of the main community developing Cockpit, many other Cockpit plugins. So, there [10:07.160 --> 10:12.160] is a very comprehensive and, I would say, very nice test suite that makes it possible [10:12.160 --> 10:18.120] to essentially write Python unit tests that then manipulate your WebUI or Cockpit plugin. [10:18.120 --> 10:27.640] In our case, the Anaconda Fedora installer web interface. And it also supports pixel [10:27.640 --> 10:33.520] testing, which we are thinking, yeah, this is nice. But then we actually thought about [10:33.520 --> 10:40.720] the other issue that most web applications have, and that's dependencies. There are dependencies [10:40.720 --> 10:47.600] being pulled from NPM for pattern fly, for React.js, and the other libraries you might [10:47.600 --> 10:55.320] need to use. And the problem with this is that the release cadence is pretty fast. There [10:55.320 --> 11:01.360] are new versions of pattern fly all the time. And it would be very easy to get left behind [11:01.360 --> 11:07.680] basically to have very big difference in using some old version and being much harder to [11:07.680 --> 11:14.080] upgrade later on. And pixel tests make it much, much more easy to update this automatically [11:14.080 --> 11:20.560] or almost automatically because you can effectively compare if you see any graphical changes from [11:20.560 --> 11:25.840] the old to the new version. Same thing for any changes for the WebUI. You can easily [11:25.840 --> 11:31.880] see what the new state looks like if you see some changes that are expected, if you change [11:31.880 --> 11:38.000] some label or add a button, or if the layout is totally wrong. So, yeah, this is something [11:38.000 --> 11:42.600] I can recommend for web applications. It seems to be very, not something we expected to be [11:42.600 --> 11:51.560] using, but it helps a lot. And it's a part of the Cockpit test tooling. So, okay, so [11:51.560 --> 12:01.400] how far we got? This all started about a year ago in earnest. And right now, we have a very [12:01.400 --> 12:09.280] simple but end-to-end installer images that can be used to demonstrate the WebUI. And [12:09.280 --> 12:17.040] actually, you will end up with a functional, minimal but functional system. It's possible [12:17.040 --> 12:22.720] to select an installation language. We already support geolocation like with the current [12:22.720 --> 12:29.760] GTK3 interface. It's possible to select disks. It's possible to dynamically add disks. Again, [12:29.760 --> 12:35.880] this is kind of a demonstration of some dynamic behavior we wanted to have there. That's it [12:35.880 --> 12:42.080] right now for storage. Storage, I'll talk a bit more about it later on. But that's one [12:42.080 --> 12:50.800] of our main focus points because that's like 90% of every installer. We have a review screen [12:50.800 --> 12:57.160] where you can see the settings. And where you are also told that, yeah, you shouldn't [12:57.160 --> 13:02.360] really run it right now on any production system that has any useful data because you [13:02.360 --> 13:06.880] select the disks and we will use them. We will wipe them and use them. So, that's the [13:06.880 --> 13:13.600] minimal storage we have been able to come a bit for now until we have some more comprehensive [13:13.600 --> 13:20.320] screen where you can actually keep partitions and stuff like that. And the last one is just [13:20.320 --> 13:25.520] a progress screen where you can see the installation happening, where you can see some errors if [13:25.520 --> 13:30.720] there are any where you can kind of guess how long it will take because that's not always [13:30.720 --> 13:40.840] easy to tell the user correctly. So, to have at least some pictures in the presentation, [13:40.840 --> 13:48.800] so this is in general how it looks like. If you've seen the current Anaconda, this is [13:48.800 --> 13:59.680] quite a departure from it. We decided to have a flexible result layout. And if you've seen [13:59.680 --> 14:05.000] some pattern fly applications, this should look pretty familiar. And that's one of the [14:05.000 --> 14:11.040] aims as well, like people who use cockpit or some other applications using this tool [14:11.040 --> 14:18.040] kit could be quite more familiar than seeing some a bit outdated GTK3 interface in some [14:18.040 --> 14:27.600] unfamiliar theming. So, as you can see, it's pretty similar. This is the installation destination [14:27.600 --> 14:35.080] screen. We already have some built-in help support. You can click on some of the information [14:35.080 --> 14:42.040] links. You will get a doc with help content. This is demonstrating just some simple disk [14:42.040 --> 14:49.480] selection. You can plug in an USB drive already to add more disks. We expect this to grow [14:49.480 --> 14:55.000] in functionality quite a lot for stuff like network-attached storage and more complex [14:55.000 --> 15:02.640] disk layouts. And this is the review screen. Right now it looks very similar, but again [15:02.640 --> 15:08.800] we expect this to grow quite a bit, because as we add more screens, this should directly [15:08.800 --> 15:15.120] proliferate here. And we are looking into ways how to, for example, visualize more complex [15:15.120 --> 15:21.720] storage layouts, because that will be challenging, but that was one of the pain points we got [15:21.720 --> 15:27.000] from users so far. Yeah, this is the progress screen. This is basically the last thing you [15:27.000 --> 15:31.920] will see. Then it will just tell you, yeah, you are done. So that's it, like four screens [15:31.920 --> 15:40.640] right now. But it's already producing functional systems. One other outcome of this project [15:40.640 --> 15:49.240] so far is preview image. Sorry for the long links, but essentially the main information [15:49.240 --> 15:53.160] here, if you go to Fedora Magazine and type in Anaconda, you will get a bunch of articles [15:53.160 --> 15:58.840] about the WebUI, because that's what we are writing about Anaconda right now. So there [15:58.840 --> 16:05.240] is a preview image. The idea is that we will refresh it once every time we add something [16:05.240 --> 16:11.120] visible. Right now, it's about like a month old, but I would expect some new features [16:11.120 --> 16:17.320] landing in the next few weeks. So this will be updated regularly. And that's the best [16:17.320 --> 16:23.920] you can use right now to have a feel of how the WebUI looks like. It's a self-contained [16:23.920 --> 16:32.240] image that effectively dumps F37 user space into the machine that you run it on, and please [16:32.240 --> 16:40.800] don't run it on anything production resembling. So we found some challenges, like working [16:40.800 --> 16:47.300] on this. Yeah, we have a huge amount of functionality. The project is all the current UI has been [16:47.300 --> 16:55.080] used for like nine years. So we are really trying to kind of check what is being used [16:55.080 --> 17:03.200] and what not. So we don't go insane implementing it all. So that's ongoing. We try to identify [17:03.200 --> 17:11.840] and avoid some of the UX problems we have right now. Also, and keeping things consistent. [17:11.840 --> 17:19.280] Like that's one nice thing about Pattenfly. There are pretty nice UX guidelines that [17:19.280 --> 17:31.400] you can apply on many, many things. And that helps to keep the UI consistent. Yeah, another [17:31.400 --> 17:37.280] issue is like how to run this locally. That's not that easy, actually, because the web engines [17:37.280 --> 17:45.480] are pretty monolithic, pretty big. And they come with some mainly RAM requirements, not [17:45.480 --> 17:50.280] to mention the image size requirements. And there are actually not that many usable web [17:50.280 --> 17:56.280] engines on Fedora. It's effectively a JDK WebKit or Firefox. And each one of them has [17:56.280 --> 18:02.920] some pluses, some minuses. So right now we are still comparing these two and deciding [18:02.920 --> 18:09.440] which one to use. For remote running, that's kind of not our problem that much. Even that's [18:09.440 --> 18:16.480] another issue with Pattenfly. Like if we see some corruption, some layout issues, it quite [18:16.480 --> 18:23.000] possibly would affect other Pattenfly users. And you might not need to do something about [18:23.000 --> 18:31.040] it unless, unlike if we used some very, very custom web UI stuff. [18:31.040 --> 18:39.080] For remote running, another issue is how you actually authenticate the thing, how you encrypt [18:39.080 --> 18:45.880] in a useful manner. So this is still ongoing, how we solve that. It might not be pretty, [18:45.880 --> 18:53.680] but one way is to show some certificate fingerprints to the user to show some generated passwords [18:53.680 --> 19:00.040] or stuff like that. Another option is to use custom images. That might be perfect for some [19:00.040 --> 19:06.600] cases to bother some for others. So we will see right now. The web UI image you can use [19:06.600 --> 19:13.480] right now is, this is a disabled right now. But if you use the inst.wepoi.remote option, [19:13.480 --> 19:18.080] you can actually access the web UI remotely. But you need to pass it because it's totally [19:18.080 --> 19:30.440] unsecure right now. These mechanisms are not yet in place. So okay, this is really in planning [19:30.440 --> 19:35.280] stages and we don't have much time to talk about it. But the main focus is definitely [19:35.280 --> 19:41.800] storage. This will be big. We plan to have something that you can manually do, something [19:41.800 --> 19:50.840] that guides you. And it should start landing in the next few preview image releases, definitely. [19:50.840 --> 19:58.680] And yeah, more screens, definitely. The priority is driven by the next, the first image we [19:58.680 --> 20:04.560] could reply to, basically. So right now there is some date and time work already running. [20:04.560 --> 20:09.400] We have some backups for user and through password configuration. We need to add the [20:09.400 --> 20:14.920] error reporting, definitely. And other stuff. Definitely add-ons. Already the UI supports [20:14.920 --> 20:26.200] them. We need to keep it. And yeah, I think this is actually, yeah. So this is, uh-huh. [20:26.200 --> 20:30.920] So this is the, this is the effect of the last slide. And it's, I think we can start [20:30.920 --> 20:37.200] with the questions just quickly. Like, storage is a big focus. This is a way you can provide [20:37.200 --> 20:44.200] feedback to us about it. And let's start with the questions. Thanks. [20:44.200 --> 20:53.840] Hey, Martin. I don't have a question per se. Oh, yeah. Right. Say, um, I really appreciate [20:53.840 --> 20:58.680] the stuff that you folks are doing. I tried doing this myself by wrapping kick-start with [20:58.680 --> 21:04.880] ViewJS, Flask. Um, and I thought that it would be really feasible, really easy thing to do. [21:04.880 --> 21:09.040] But when I started implementing it, I came to know the kind of entry cases that I was [21:09.040 --> 21:14.520] to take care of. So I'm totally looking forward to what you folks end up doing. All the best. [21:14.520 --> 21:15.520] Thanks. [21:15.520 --> 21:26.960] Okay. Um, oh. Anaconda has now just nice features as, as escaping to a terminal, for instance, [21:26.960 --> 21:32.520] to bypass things Anaconda can't do at the moment. Do you retain that too? What plan [21:32.520 --> 21:38.160] do you do? So the current text interface, as well as like, if you, if you can access [21:38.160 --> 21:43.960] the machine locally, it should still be possible to do like anything in the terminal that you [21:43.960 --> 21:49.280] can do today. And you should be also able to use the existing text interface. We won't [21:49.280 --> 21:55.040] be changing that. Yes. But you, you can escape the web interface and get a terminal or what [21:55.040 --> 21:59.480] is the way to do that? This is not like yet settled. Like if you will include it, but [21:59.480 --> 22:03.920] the cockpit project has built in terminal emulated. I could imagine this to be included [22:03.920 --> 22:08.840] in the VAP UI. So we might be able to include it in our VAP UI as well. [22:08.840 --> 22:22.720] Would be nice if you do it. Yes. Thanks. Thanks for the feedback. [22:22.720 --> 22:26.320] Thank you for the talk. I think this is very interesting. And I think it's a good idea. [22:26.320 --> 22:31.080] You know, certainly convenient to set up headless machines this way. But at the same time, I [22:31.080 --> 22:38.120] was wondering, I think it was Alex Larson who wrote this Broadway backend for GTK. So basically [22:38.120 --> 22:45.040] you could use GTK and it would output to what goes into a web browser. And I, you know, [22:45.040 --> 22:49.400] just comes to my mind, why not use something like that instead? Because I think that if [22:49.400 --> 22:55.360] you, we want to continue to invest in GTK and technical technologies using GTK because [22:55.360 --> 23:01.240] we need GTK for Fedora, we don't really need web for sure. And so if we can end up using [23:01.240 --> 23:06.160] GTK and investing more resources there, maybe this makes it just overall better for the [23:06.160 --> 23:10.120] whole health of the ecosystem. And we get our web UI too. [23:10.120 --> 23:15.440] So thank you. Yeah. I must say I don't have like really like very recent information about [23:15.440 --> 23:21.600] it, but we looked at it a while ago basically to the, at the Broadway technology. It definitely [23:21.600 --> 23:26.200] looked interesting, but it didn't, it looked more like a Tehdemo back then. It could have [23:26.200 --> 23:31.040] progressed since then, but I think there have been some issues like with authentication [23:31.040 --> 23:37.600] or possibly performance. So yeah, that's a good point, but I don't have like latest [23:37.600 --> 23:40.600] information right now for it. Okay. [23:40.600 --> 23:56.040] I mean, then you can have all of your, you can have the GTK and you have your web, everyone [23:56.040 --> 24:10.480] else. Well, that's another question. Before Fedora's 37, we had a discussion about soft [24:10.480 --> 24:18.760] rate installation using the BIOS boot machines and we found a good solution, but Anna couldn't [24:18.760 --> 24:25.400] ask currently a bit strange installing software rate on ify systems because we don't use [24:25.400 --> 24:31.400] a ify system partition, but a rate partition. Do we have a chance to get the fix too? [24:31.400 --> 24:37.800] I'm not sure. Like I, like I, it's not that many people actually in the installer team [24:37.800 --> 24:43.800] and I have been very much concerned and concentrated on the, on the web UI right now for the couple, [24:43.800 --> 24:47.840] last couple months, but definitely if you reach out to us, like we have a mailing list [24:47.840 --> 24:53.360] or we have a metrics channel, I think right now already for Fedora. So please reach out [24:53.360 --> 24:55.680] to us using some of these channels and we can look at it. [24:55.680 --> 25:00.680] Yes. Oh, you can do that. [25:00.680 --> 25:21.640] Is it, is it possible to provision the machine from the cockpit because you can already create [25:21.640 --> 25:27.040] in cockpit virtual machines. So it would be nice to be integrated in one place in one [25:27.040 --> 25:29.800] console. Is it possible or do you have such plan? [25:29.800 --> 25:35.120] I think it's a, I don't think we have like integration for it right now, but that's an [25:35.120 --> 25:39.880] interesting idea. And like we have been thinking for stuff like satellite and some other provisioning [25:39.880 --> 25:45.000] mechanisms that it would make sense to more closely integrate with the installer, with [25:45.000 --> 25:51.160] the web UI because you could avoid the certificate and authentication issues. If you could, for [25:51.160 --> 25:55.040] example, inject something into the image. So that could, that could work. Like you could [25:55.040 --> 26:01.440] have like create machine or provision bare metal, whatever. And it could like include [26:01.440 --> 26:08.280] some like trust chain anchors, whatever into the installation run. And then you could then [26:08.280 --> 26:12.800] directly connect to the, to the machine. Yeah, we have been thinking about it, but we haven't [26:12.800 --> 26:18.520] yet implemented something like this, but it seems like obvious choice for some mechanisms. [26:18.520 --> 26:22.640] And yeah, with integrating it like this with cockpit machines, that could be a nice idea. [26:22.640 --> 26:24.640] So thanks for the suggestion. Okay, thanks. [26:24.640 --> 26:50.640] You're at it, guys. Okay. Thank you, Mark. Thanks a lot.