Building a Web UI for the Fedora installer
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/62000 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Web 2.0Distribution (mathematics)BitComputer animation
00:31
Graphical user interfaceArchitectureMilitary operationDistribution (mathematics)Electric currentRemote Access ServiceExecution unitSoftware testingData managementPhysical systemKeyboard shortcutConsistencyWeb browserSoftware developerComputer-generated imageryProjective planeVideo game consoleUser interfaceMultiplication signPlug-in (computing)Task (computing)Graphical user interfaceWeb 2.0Internet der DingeMaxima and minimaCartesian coordinate systemRight angleArtistic renderingTwitterKeyboard shortcutSoftware developerPhysical systemMedical imagingUsabilitySoftware testingPairwise comparisonPoint (geometry)Configuration spaceLibrary (computing)Unit testingContext awarenessImage resolutionMathematicsSystem administratorOcean currentBitRemote procedure callExergieCASE <Informatik>Firewall (computing)Computer animation
07:13
Pattern languageUser interfaceView (database)Web browserComponent-based software engineeringTangible user interfaceElectric currentGraphical user interfaceSoftware testingSoftware frameworkExecution unitPixelSimilarity (geometry)Regular graphTouchscreenComputer-generated imageryElement (mathematics)CodeRight angleBitUser interfaceProjective planeGUI widgetRevision controlDifferent (Kate Ryan album)Library (computing)Web applicationWeb 2.0Front and back endsCASE <Informatik>Execution unitSystem callSoftware testingPlug-in (computing)PixelGraphical user interfaceMathematicsSoftwareModul <Datentyp>TouchscreenLogicState of matterOcean currentBridging (networking)Suite (music)Distribution (mathematics)Software frameworkWritingNetzwerkverwaltungMereologyFunctional (mathematics)Computer animation
11:50
Physical systemFormal languageMiniDiscTouchscreenTraffic reportingInformation managementExecution unitVacuumComputer-generated imageryContent (media)FeedbackSource codeFocus (optics)User interfacePattern languageTouchscreenError messageArithmetic progressionType theoryPartition (number theory)MiniDiscInformationContent (media)Physical systemFocus (optics)Data storage deviceProduct (business)Functional (mathematics)BitCartesian coordinate systemResultantProjective planeWeb 2.0Medical imagingMultiplication signSoftwareSelectivity (electronic)Ocean currentFormal languageSpacetimeOnline helpSet (mathematics)Right angleVirtual machinePoint (geometry)Complex (psychology)Computer animation
16:37
BuildingFunction (mathematics)Electric currentGraphical user interfaceConsistencyFeedbackLocal ringElectronic visual displayComputer-generated imagerySpacetimeUniform convergenceAddress spaceVirtual machineRegular graphPublic key certificateAerodynamicsWeb browserFingerprintMedical imagingRight angleWeb 2.0Computer configurationConsistencyProjective planeMechanism designPasswordFingerprintImage resolutionFunctional (mathematics)Public key certificateUsabilityComputer animation
19:25
Configuration spaceData storage devicePartition (number theory)Computer configurationGreatest elementRootTraffic reportingError messageSource codeSoftwareMedical imagingConfiguration spaceRight angleError messageElectronic program guideRootFocus (optics)Level (video gaming)PasswordMultiplication signComputer animation
20:22
Data storage deviceArchaeological field surveyComputer configurationPublic key certificateINTEGRALWeb 2.0Virtual machineProxy serverGoodness of fitVirtualizationFeedbackBit rateBootingData storage deviceInformationFocus (optics)Ocean currentChainAuthenticationRadical (chemistry)SatelliteProjective planePlanningMoment (mathematics)BitUser interfaceAxiom of choicePartition (number theory)EmulatorMultiplication signWeb browserEmailDemo (music)Metric systemFunction (mathematics)Physical systemElectronic mailing listFront and back endsComputer animation
26:40
Point cloudProgram flowchart
Transcript: English(auto-generated)
00:05
Hello, welcome to my talk about building a web UI for the Fedora installer. So my name is Martin Koman and I work in the team that's building the Anaconda installer used by Fedora, RHEL, CentOS and related distributions.
00:25
First I would like to talk a bit about why we decided to actually build a web UI for our installer. First, very shortly about the Fedora installer project. The name of it is Anaconda, which is very confusing for some people doing Python in
00:44
the scientific domain, because there is a very similar project in that it's like a Python thing, but it's called the same as V, but I think we are older. So anyway, right now we have a GTK3 UI for the installer. We have a text-based UI.
01:01
It's also possible to fully automate the installation. We have things like add-on support and we are used, as I mentioned, by Fedora, RHEL, CentOS and others. This talk is basically concerning only the graphical user interface. We don't expect to have any changes for the text-based interface and the kickstart-based
01:25
automation in the context of the web UI. Why did we actually choose to do something about the current graphical interface and why did we choose to start working on a web UI?
01:42
One of the points is that the current GTK interface comes from the year 2013, kind of looks like early GNOME 3. By coincidence, maybe it was built at the same time, basically, and over time we added new features, we fixed bugs, we adapted to various Fedora changes, for example, and
02:05
the stuff kind of got bolted on. Not always it was possible to change the UI. So in some cases it's getting a bit clunky already. Another issue is that some of the technology we built it on is getting a bit old right
02:23
now. GTK 3 is not that old at the moment, but already you have GTK 4, eventually we would have to port it. One of the issues is, for example, the Fedora installation image. The Fedora project tries to have minimal dependencies of applications.
02:43
So over time you want to have the minimum amount of libraries, so we would have to quite possibly migrate to keep the image sizes small, that's one of the reasons. We also still run on top of X, there is even some hard dependency right now on keyboard
03:00
switching during the installation, so this is something we would have to address anyway. The remote access to a graphical installation right now is not the best, it's based on VNC, so it's unsecure, it's not very efficient, it requires you to have a graphical system
03:20
running on the host that you are installing, and you need a special application that might not be available, that users might need to install. So that's one of the issues. And also, I'm not saying it's not possible to test GTK 3 interfaces, but basically it's not that simple, and we don't really have any unit test coverage.
03:42
There are people from, for example, the Federac UA community that do test Anaconda, but what they are using is basically a screenshot or graphical bitmap-based testing right now. So this is something that could be improved. And also, what we have seen in the past years is that there seems to be a clear trend
04:06
towards using web UIs for system management. Some of you might still remember some of the system config tools used on Fedora and CentOS and Trell that used to be available to configure stuff like services, networking,
04:21
firewalls. All of these, over time, effectively became cockpit plugins for the cockpit web console. So this seems to be the trend overall for system management, as far as we can tell. So, what we kind of found out, there are some benefits of doing something about the
04:44
current UI situation and doing something about it with a technology-based UI. So while we are at it, we can address some of the UX issues we have right now, because it's effectively a fresh start right now. It's easier to achieve consistency, because you are building the whole thing, so you can
05:05
make sure that it feels similar. It's using the same concepts, the same workflows for everything, hopefully. Also another thing is that given the proliferation of web UIs everywhere, basically, there seems
05:23
to be much bigger community of users, of developers of these technologies. And there is, overall, more documentation, there's even more resources for non-developer roles like UX designers, or usability testing projects, and this seems to be, unfortunately,
05:46
quite lacking in many native UI libraries right now, in comparison to the web technologies. And also, like, one quite big point for it is that using a web UI, just to be specific,
06:02
we are going to use the web UI both locally and remotely, so we want to run it for the local graphical session, if any, but also it makes it much, much easier to access the installation remotely. So for any headless installations, it should be much easier for the users using the installer
06:24
to connect securely and much more efficiently to the host that is being installed. Also, the host doesn't have to contain any graphical dependencies effectively, because all the rendering is happening on the client, so the installation image could be much smaller,
06:40
and also the installation time, resource requirements could be much, much smaller. That could be an issue for stuff like Raspberry Pis or some IoT SBCs, which are perfectly fine for the tasks you will be using them, but if you try to do a graphical installation on them, bearing possible issues with drivers, it might need much more resources
07:03
to just install, to bring up the graphical interface than it will be using for its lifetime of doing some useful work. So let's talk a little bit about the technical details of the tools that we are using to build a UI for the installer right now.
07:24
So this is the overall architecture. The installer is already modular, in that it has a Python backend, which has a D-Bus interface. Then we are using Cockpit to provide us a bridge between D-Bus and the web application,
07:43
which itself is then written with ReactJS for the logic and Patternfly for the web UI widgets. The current Anaconda with the GTK3 UI, with the text UI, and even with the kickstart support, is actually using the same Python backend, and even the GTK3 UI
08:03
already is communicating with the backend via D-Bus. So this makes it possible for us to right now work in parallel, that we are building the web UI next to these other UIs right now. Just instead of directly calling D-Bus, you have Patternfly widgets talking via D-Bus,
08:28
calling D-Bus calls from the backend. This is very similar to Cockpit plugins in general. Usually you have the networking screen in Cockpit, for example, and what it does,
08:40
it's talking to network manager via this bridge. It's doing D-Bus calls from Jabasub. That's basically the idea of Cockpit, and we are reusing this for our project. As I've already mentioned, it's not about another UI that you can remotely access
09:03
while keeping the current graphical interface next to this. Eventually, once we cover all the necessary functionality for the given project or product, it should replace the current graphical interface. But right now it's being developed next to it, and thanks to the modular backend
09:22
thanks to the D-Bus interface, it's not that hard to do it. Also one more thing that we found very useful is the Cockpit test framework. This is addressing the issue I've mentioned previously about no unit tests
09:40
for the graphical interface. This is something that has been developed for the Cockpit project itself, which directly maintains a lot of the screens you will see when you install Fedora or CentOS or some such distribution and enable Cockpit. But there are also many outside of the main community developing Cockpit,
10:05
many other Cockpit plugins. There is a very comprehensive and I would say very nice test suite which makes it possible to essentially write Python unit tests that then manipulate your web UI or Cockpit plugin, in our case the Anaconda Fedora installer web interface.
10:25
It also supports pixel testing, which we are thinking this is nice, but then we actually thought about the other issue that most web applications have and that's dependencies. There are dependencies being pulled from NPM for Patternfly,
10:44
for ReactJS and other libraries you might need to use. The problem with this is that the release cadence is pretty fast. There are new versions of Patternfly all the time, and it would be very easy to get left behind basically
11:02
to have very big difference in using some old version and being much harder to upgrade later on. Pixel tests make it much, much more easy to update this automatically or almost automatically because you can effectively compare if you see any graphical changes from the old to the new version.
11:22
Same thing for any changes for the web UI. You can easily see what the new state looks like. If you see some changes that are expected, if you change some label or add a button, or if the layout is totally wrong. This is something I can recommend for web applications.
11:40
It seems to be very not something we expect it to be using, but it helps a lot. It's a part of the Cockpit test tooling. How far we got? This all started about a year ago in earnest. Right now, we have very simple but end-to-end installer images
12:05
that can be used to demonstrate the web UI. Actually, you will end up with a minimal but functional system. It's possible to select an installation language.
12:20
We already support geolocation like with the current GTK interface. It's possible to select disks. It's possible to dynamically add disks. Again, this is kind of a demonstration of some dynamic behavior we wanted to have there. That's it right now for storage. I'll talk a bit more about it later on,
12:41
but that's one of our main focus points because that's 90% of every installer. We have a review screen where you can see the settings and where you are also told that you shouldn't really run it right now on any production system that has any useful data
13:01
because you select the disks and we will use them. We will wipe them and use them. That's the minimal storage we have been able to come up with for now until we have some more comprehensive screen where you can actually keep partitions and stuff like that. The last one is just a progress screen
13:21
where you can see the installation happening, where you can see some errors if there are any, where you can kind of guess how long it will take because that's not always easy to tell the user correctly. To have at least some pictures in the presentation,
13:41
this is in general how it looks like. If you've seen the current Anaconda, this is quite a departure from it. We decided to have a flexible result layout and if you've seen some pattern fly applications,
14:02
this should look pretty familiar and that's one of the aims as well. People who use Cockpit or some other applications using this toolkit could be quite more familiar than seeing some a bit outdated GTK3 interface in some unfamiliar theming.
14:22
As you can see, it's pretty similar. This is the installation destination screen. We already have some built-in help support. You can click on some of the information links. You will get a dock with help content. This is demonstrating just some simple disk selection.
14:43
You can plug in an USB drive already to add more disks. We expect this to grow in functionality quite a lot for stuff like network attached storage and more complex disk layouts. This is the review screen.
15:01
Right now it looks very similar, but again we expect this to grow quite a bit because as we add more screens, this should directly proliferate here and we are looking into ways how to, for example, visualize more complex storage layouts because that will be challenging, but it was one of the pain points we got from users so far.
15:24
This is the progress screen. This is basically the last thing you will see. Then it will just tell you, yeah, you are done. That's it for screens right now, but it's already producing functional systems. One other outcome of this project so far is a preview image.
15:45
Sorry for the long links, but essentially the main information there, if you go to Federal Magazine and type in Anaconda, you will get a bunch of articles about the Web UI because that's what we are writing about Anaconda right now. There is a preview image.
16:01
The idea is that we refresh it every time we add something visible. Right now it's about a month old, but I would expect some new features landing in the next few weeks, so this will be updated regularly, and that's the best you can use right now to have a feel of how the Web UI looks like.
16:23
It's a self-contained image that effectively dumps F37 user space into the machine that you run it on, but please don't run it on anything production resembling. We found some challenges working on this.
16:43
We have a huge amount of functionality. The project is old. The current UI has been used for nine years, so we are really trying to check what is being used and what not, so we don't go insane implementing it all. So that's ongoing.
17:02
We tried to identify and avoid some of the UX problems we had right now. Also keeping things consistent. That's one nice thing about PatternFly. There are pretty nice UX guidelines that you can apply on many things,
17:23
and that helps to keep the UI consistent. Another issue is how to run this locally. That's not that easy, actually, because the web engines are pretty monolithic, pretty big, and they come with some mainly RAM requirements,
17:45
not to mention the image size requirements, and there are actually not that many usable web engines on federal. It's effectively GDK WebKit or Firefox, and each one of them has some pluses, some minuses, so right now we are still comparing these two
18:02
and deciding which one to use. For remote running, that's kind of not our problem that much. That's another issue with PatternFly. If we see some corruption, some layout issues, it quite possibly would affect other PatternFly users and they might not need to do something about it,
18:23
unlike if we used some very custom web UI stuff. For the remote running, another issue is how you actually authenticate the thing, how you encrypt in a useful manner.
18:41
This is still ongoing, how we solved that. It might not be pretty, but one way is to show some certificate fingerprints to the user, to show some generated passwords or stuff like that. Another option is to use custom images. That might be perfect for some cases,
19:01
too bothersome for others, so we will see right now. The web UI image you can use right now, this is disabled right now, but if you use the inst.webui.remote option, you can actually access the web UI remotely, but you need to pass it because it's totally unsecure right now. These mechanisms are not yet in place.
19:27
Okay, this is really in planning stages and we don't have much time to talk about it, but the main focus is definitely storage. This will be big. We plan to have something that you can manually do,
19:41
something that guides you, and it should start landing in the next few preview image releases, definitely. More screens, definitely. The priority is driven by the first image we could replay, basically.
20:01
Right now there is some data and time work already running. We have some mockups for user and root password configuration. We need to add the error reporting, definitely, and other stuff. Definitely add-ons. Already the UI supports them. We need to keep it.
20:23
This is effectively the last slide, and I think we can start with the questions. Just quickly, storage is a big focus. This is a way you can provide feedback to us about it. Let's start with the questions.
20:41
Thanks. Hey, Martin. I don't have a question per se. Oh, yeah. I really appreciate the stuff that you folks are doing. I tried doing this myself by wrapping Kickstart with Vue.js, Flask,
21:01
and I thought that it would be a really feasible, really easy thing to do, but when I started implementing it, I came to know the kind of intricacies that I was to take care of, so I'm totally looking forward to what you folks end up doing. All the best. Thanks.
21:22
Anaconda has now just nice features as escaping to a terminal, for instance, to bypass things Anaconda can't do at the moment. Do you retain that too, or plan to do? The current text interface, as well as if you can access the machine locally,
21:40
it should still be possible to do anything in the terminal that you can do today, and you should be also able to use the existing text interface. We won't be changing that. Yes, but you can't escape the web interface and get a terminal, or what is the way to do that? This is not yet settled, like we will include it, but the cockpit project has a built-in terminal emulator.
22:02
I could imagine this to be included in the web UI, so we might be able to include it in our web UI as well. Would be nice if you did. Yes. Thanks for the feedback.
22:23
Thank you for the talk. I think this is very interesting, and I think it's a good idea. Certainly convenient to set up headless machines this way, but at the same time I was wondering, I think it was Alex Larsen who wrote this Broadway backend for GTK, so basically you could use GTK and it would output to what goes into a web browser.
22:43
It just comes to my mind, why not use something like that instead, because I think that we want to continue to invest in GTK and technical technologies using GTK, because we need GTK for Fedora, but we don't really need web for sure. So if we can end up using GTK and investing more resources there,
23:04
maybe this makes it just overall better for the whole health of the ecosystem, and we get our web UI too. Thank you. I must say I don't have very recent information about it, but we looked at it a while ago basically at the Broadway technology.
23:21
It definitely looked interesting, but it looked more like a tech demo back then. It could have progressed since then, but I think there have been some issues with authentication or possibly performance. That's a good point, but I don't have latest information right now for it. I would check.
23:40
Okay. Then you can have all of this.
24:01
Just another question. Before Fedora's 37 release, we had a discussion about soft rate installation using the BIOS boot machines, and we found a good solution, but Anaconda is currently a bit strange installing soft rate on EFI systems,
24:24
because we don't use an EFI system partition, but a rate partition. Do we have a chance to get that fixed too? I'm not sure. It's not that many people actually in the installer team, and I've been very much concerned and concentrated on the web UI right now
24:43
for the last couple of months, but definitely if you reach out to us, like we have a mailing list or we have a metrics channel I think right now already for Fedora, so please reach out using some of these channels and we can look at it.
25:14
Is it possible to provision the machine from the cockpit, because you can already create in cockpit virtual machines,
25:23
so it would be nice to be integrated in one place, in one console? Is it possible, or do you have such plan? I don't think we have integration for it right now, but that's an interesting idea. We have been thinking for stuff like satellite and some other provisioning mechanisms,
25:41
that it would make sense to more closely integrate with the installer, with the web UI, because you could avoid the certificate and authentication issues if you could, for example, inject something into the image, so that would work. You could have create machine or provision bare metal, whatever, and it could include some trust chain anchors, whatever,
26:04
into the installation run, and then you could then directly connect to the machine. We have been thinking about it, but we haven't yet implemented something like this, but it seems like obvious choice for some mechanisms, and with integrating it like this with cockpit machines,
26:21
that would be a nice idea, so thanks for the suggestion. Okay, thanks. Okay. Thanks a lot.