 OK. So, welcome to the Fedora 36 release party. I'm Martin Coleman from the Anaconda installer team. So what is Anaconda? Anaconda is the installer that most people will get to use at least once when they are using Fedora or rel or some of the related distros. And that's what we are working with in our team. And what I want to talk about today is a new project related to the Anaconda. And basically, it's about the web UI for the installer. So why we are building a web UI for installer? Basically, the installer, one of the ways that user can interact with the installer is graphical user interface. The current interface at this point is about 9 to 8 years old. And it's built on GTK and Python code. And we are seeing an accumulating amount of issues with this interface. One of them is, for example, various UX problems that come out from how the layout works, how the underlying technologies represent this user interface, and are not really easy to fix without major changes. Also, for those who have some lower level experience with the graphical stack in Linux distros, we are not yet valent compatible, unfortunately. And it also goes down to the technologies used for the current graphical user interface. And also, this is GTK3, what we are using. Some of you might have noticed that this is not the latest GTK. There is now GTK4. And over time, we would have to touch this interface on lower level as well, because it would be most likely necessary in the next few years to also migrate to the newer GTK version. Like we did, for example, in the past, like the previous graphical user interface for Anaconda was on GTK2. One quite a big point at the moment is that remote access to the installation, which is, for example, pretty useful for popular single board computers like Raspberry Pi and similar, is pretty inefficient and not really secure due to the way how it basically scraps pixels from low rendering and sends them over network. So that's something that we would like to fix as well in the future of the graphic interface for the Anaconda installer. From the developer point of view, we don't really have good unit test coverage for the current graphical interface. Again, it kind of goes to the stack we are using. As far as I know, there is no major built-in tooling for GTK Python interfaces. There are various ways how you can do it, but they are not that easy. So while we have quite good coverage for our back end and other parts of the installer, we are kind of flying blind when we are making major changes in the interface, even though there are like downstream tests for Fedora or the rel installer. For day-to-day development, we don't yet really have coverage for the interface and doesn't seem to be very easy to do that now. Another thing that we are noticing is not that it's already, I think, visible in Fedora as well with, for example, cockpit. As far as I can tell, it seems to be pretty popular, and it basically replaced all the small GTK applications that people used to configure their firewalls, their samba shares, and stuff like that. It's all basically plug-ins in the cockpit web console, and in the rel space, it's even bigger change where almost all of these bigger software projects have web interfaces these days. So OK, let's go next. So what we are, how we are going to fix this and improve the situation. So the idea is that when we are going to change it, we might as well do it properly and try to fix as many of these issues as possible with the clean sheet design of the user interface, not just using the same text tag, but trying to pick a bit better one, as well as fixing the design issues. For this, for example, for the design itself, we are starting with a user designer that's working as part of our team from the day one. We are not just blindly implementing some ideas. We have sets of mock-ups that go through different iterations, that are based on best practices of current week's development, and then we are turning those into the new UI for Danakonda. We also want this to be valent compatible from the start, so we are not starting, basically, with technological debt from the start of this effort. Also, we want to pick a graphical interface tag that would be future proof, and that would have big user community. So it's not, sometimes it looks like we are one of the last big GTK Python applications in major usage in Fedora, it seems like that. Most of the other stuff is apparently using other technologies, and it was not always easy to figure out some weird regressions in GTK over the years. The other improvement we want to achieve is make easy access to Danakonda remotely, basically first class citizen, to make it secure, to make it efficient, and possibly also to avoid the need to render the UI locally, and then send it over the network. That results in big installation images, because they need to include the graphical stack. It requires a lot of network traffic, and it would be ideal to basically move this to the client, so you can then easily control the installation of your Raspberry Pi without the system being text by rendering the interface and inefficiently sending it over the network. It should just handle the installation itself. Ideally, we want to pick something up that users are already familiar with, with the UX principles of this system. When they enter the installer UI, they are not confused, basically. That was actually one of the ideas for the current interface, and it kind of looks like a norm shelf from 2009 or something like that. But unfortunately, their design language kind of changed, but ours didn't, so it looks kind of weird at the moment, and it's not that familiar to users in the concepts that remain to be used there, so we would like to keep in touch with something that people regularly use in other cases. So what we decided to use for this effort is web technologies, basically. To be more exact, it's cockpit and it's button fly. So, as I've mentioned already, cockpit, as most people know, it is a web console for mainly Fedora and trial systems, but I know that it supports much more than these two distributions, and it's not basically just the interface itself. It's also a technology that makes it possible for a web application to interact with the system and control it. It exposes the bus interfaces and file system access, so the web interface can easily display log files, communicate with the bus demons, and even present a shell interface via web browser. Let's also work on some even more advanced stuff like virtual machine access and control. So what we are using is cockpit for exposing the back end of Anaconda, which is a set of processes that provide a bus interface, and then we use web UI based on button fly. Button fly is effectively as a set of web components and widgets, as well as some design language, web UX designer toolkits and UX design guidelines that make it possible to do, I would say, pretty nice web interfaces that not only are accessible, but also can handle various screen sizes, mobile use cases, and butterfly is also the stuff that you actually see when you are using cockpit and also some of the enterprise software suites running on rail like satellite and OpenShift. This is all using the button fly components, so people using cockpit and these software suites should be, in general, familiar how these components look like. It's just like we present them in the installer use case. So how this actually solves the issue. So the familiarity should be solved by people being used to these interfaces from other projects. The remote access problem is solved by basically providing a web interface. So on the install image itself, you basically need just the web server and the Anaconda backend, and the interface is rendered and presented to the user locally. So it enables very limited hardware to have a nice graphical interface because it doesn't need to render it anymore. It makes it also possible to create very small installation images because you don't need to drag, like X and geographical toolkit and all the rendering machinery with it. And also, unlike the current solution, which is basically VNC shipping the pixels of the GTK interface over network, this can be properly secured using normal HTTPS, unlike the VNC, which is not encrypted and the authentication is not very strong. And of course, the idea is that this will be not just a remote web interface. This will be also something that will be running locally as usual as what the users are used to at the moment. And this is just a web view running as a full-skin application, which is easily well incompatible. So I've already talked a bit about this. So how does the implementation of this Anaconda VPI looks like? The backend is still the same. Already the GTK interface, as well as the text interface, which will stay the same even with the web UI, it's all communicating with the Anaconda backend via debas. So this doesn't really change and the web interface will be just another interface, at least initially in parallel with the GTK one that communicates with the backend and controls the installation. Mainly, we will communicate via debas with the backend, but we are actually using also the feature of the cockpit tooling to enable access to files on the system. So this is what will be used to display log files in the web interface. And also, we are already using it to work with the Anaconda config files. There was actually a talk a couple hours earlier about Anaconda config files and we are using this cockpit bridge to grab the config file, then we parse it in the web UI and work with the values from it. So I've already mentioned cockpit, I've already mentioned button fly. I also need to mention ReactJS, which is what button fly is based on. It's a reactive modern JavaScript framework and that's basically what the logic of the web UI itself is implemented in. And these three things is effectively what, that's the web UI. It's cockpit for communication with the system, it's button fly for the components and then in the middle basically is the ReactJS to provide the client-side logic basically in the web interface itself. When we started this project, we decided to build something that would be useful and can be used, tested and that we can get feedback for in realistic circumstances. So we decided to do a minimal product for this and we based it on the Federal Workstation use case. Basically when we put aside all the screenshots of the Anaconda Hub from different Anaconda install images, on the Federal Workstation there are the least screens because Federal Workstation prefers to do a lot of the configuration after reboot to the target system. So we decided to use this as the first thing that we want to control via the web UI. And basically at the moment it's very simple but already provides a lot of the similar functionality as the Federal Workstation. One thing you might notice if you know the current Anaconda design, we switched to a wizard model. We no longer have the hub and spoke model with screens that you go back and forth between but we have an ordered collection of screens with the option to go back at any time. So this is the first screen that users will see when you select the language. The next screen is very simple storage configuration screen. For the minimal product version, we just make it possible to select which disks will be used and then they will be automatically partitioned, including removing any data. So please, if you want to try this out, eventually when we do some test days, take this into account, it will kill all your data and that's on purpose. So please be sure. And I think we already write it somewhere, so we are fine. The next screen is a review screen and the last one is progress screen. So to get quickly around it, that's even when we add more stuff, we kind of want to keep the general structure. So like most likely, we will always start with selecting the language. The storage configuration will definitely be more advanced and we will then present some summary of what the user has selected before we commit to unrevertible changes to the system. But they will be definitely based on the target system more or less screens, different sets of screens and as before, this will need to be dynamic. So this is like really the beginnings of this effort and even though this will produce a semi-working system already, that it will, we have bootable images, we have tested the interface locally and remotely, it's really early still. So the next steps for this effort are, we will do some sort of a test day, most likely during the fall timeframe. If you are following the general federal channels like the community block or the federal deval list and others, most likely you will see it when we are so far, there will be some sort of an invite. If you are interested, you can definitely take part. And after the MVP, we most likely will be concentrating on storage and storage improvements. Because this always has been the most complex and most required for real life installer use cases part of the Anaconda and definitely also other screens. Even though for example federal workstation handles user creation after installation, other projects not, they need that. So we will definitely work on user creation screens and for configuration. And we are even thinking about possibly using some screens or widgets from cockpit project itself, possibly because the functionality is very similar. So that's something that we will need to investigate if we would be able to share the effort with cockpit or if it's not really possible for the incision environment being too different. Also the payload we are using at the moment is basically a tarbol that is unpacked to the target system for the MVP. We definitely need to support the DNF so package-based payloads and other payloads that people need for real-world use cases. And of course Anaconda add-ons that has been something introduced years, years ago with this then new UI and we definitely need to keep this working already. There is an Oscar add-on, there is skydump add-on and possibly others for specific user use cases. And that's it. So if you have any questions, so I think we are basically like the last talk and we should have some minutes for that, so please fire away and we should be able to respond. Sure, go ahead. Great, so how do you handle the remote installation, actually? What? How do you handle the remote installation because you don't configure any network, so how do you figure out where the Anaconda UI is running? Yeah, so at the moment, basically, the machine should get, basically, we are using IDHCP, so that's one way how you can do it. You can make sure, like the, you can see from the IDHCP cell robot address the machine got or you can make sure it gets this address, especially if you are provisioning some VMs, that's quite easy to do. And other than that, yeah, this is something we are still looking into. That's actually like the address is one problem. The other one is that is how to secure this because we have the encryption, we can generate some certificates and cause these nice certificate warnings for users. But how do we actually tell this is the user who started the installation? So we will need to some way how to embed some secret either into the images or the way they are started. So then people can then securely connect to these machines. Like one idea has been like, there is quite a lot of interesting projects based on image builder. So possibly you could generate an image with a secret for yourself that might even call some service and tell you, hi, I'm alive and I'm running there, please connect and tell me what to do. Other than that, there is a possibility to inject and configure even the networking, inject the secret and configure networking by a kickstart, which could be passed via PICC or again embed it in the image. So basically it's the same what we had to handle before. Like if you wanted to remotely control the installation, already you had to get the address somehow, either like from graphical console of the machine, which might not always be possible, or you had to like pre-configured a networking by a kickstart or something. But like the difference should be like, now it should be actually working, not really an efficient, unsecured VNCS before. Also like as I've mentioned this SBCs, like these like small, cheap armboards. I think in this case you can easily make it like, you can connect to it over like network, USB networking and it will always get the same IP address and stuff like that. Any other questions? Should I? Yeah, okay. So I know from other information channels that your intention is not to have 100% feature parity with the old GUI. So is there any, is somewhere represented what you are going to drop? So this is again like something we are still investigating because we are sure like the IT is not like static thing. So I'm sure that something we added like nine or 17 or 20 years ago and we are still carrying it over, might not no longer exist like maybe some of these like really fancy storage technologies over network with special network adapters and cables might actually not exist in reality anymore. So this is something that we want to investigate and check like if, especially for the example the advanced storage technologies. We have a lot of support for those and we really want to basically do a, to check actually if these are actually even something that's for example supported by Fedora and Rail anymore on driver level if we are not carrying super complex UIs for something that actually can no longer work with modern kernels for example. So this is something we want to check. We want to definitely reach to users and to find out like what's the highest priority for them and possibly even like move some stuff to add-ons or possibly again like we are investigating if we could possibly provide some parts of the functionality via cockpit plugins, existing cockpit plugins. So that could be also something that could be shared with some other projects. But yeah, definitely we want to check what's actually used by people. We don't really have any usable metrics and I don't think we can really get those easily due to the way how to install this run. But we want to clean house a bit definitely. But yeah, not really any announcements just yet. Okay, thank you. Any more questions? So I think that's it. So thanks for attending. Hopefully it was useful for you and looking forward to seeing you on the test day in fall. Thanks a lot.