 So I guess we can start the next session, which will be about Anakonda's web UI. I'm Vladimir Slavik and this is Martin Koloman and hopefully we'll talk to you and then you will talk to us. So what is the web UI? I guess you saw some pictures somewhere, maybe on phonics or I don't know where. Disusual places. What is it for us as developers of Anakonda? Well, it's a new UI so it's a chance to fix the mistakes we made with the previous one. It's an opportunity to do things better. Hopefully with the help of somebody who knows what they are doing, which might not be always necessarily us. And it's also far into other technologies than we used so far. What it looks like? Well, it's blue I guess. It's the first thing you can tell. So that matches the Fedora branding quite nicely I guess. The one thing that's very different, I guess you know already how Anakonda looks. What the new UI looks like is that it's a wizard so it has steps on it. So that's the main difference. Otherwise, well, there's buttons, there's things to click. So I guess that's the part that's not so different. And well, at the moment it's very limited so I can't show exactly more than these two pictures, but it already works. So there's, I guess you can look at this and see that there's a lot of the design language shared with web applications which, well, even that the new UI is a web UI, so it's technically a web application, so it's no surprise. And yeah, next slide please. So how does it work technically? Well, we build heavily on cockpit as a technology, not necessarily as a, well, as a thing that you would see in the UI itself. The UI itself is a plug-in cockpit and so the GTK UI is reduced to just, you know, a frame with the GTK browser which shows this thing. The web page is in pattern fly and react because that's what the cockpit does. And cockpit itself actually bridges the gap between the page and the Divas API that we have for the actual Anaconda code that does the work of the installing and setting up things. So that means that the backend is the same as we currently have, so it's just the buttons that change, there's no changes in the backend for this. It's actually just, you know, adding things to export, I don't know, list of languages that should be in front of the others and so on. So there's very minimal changes to that. So, yes, next please. Oh, one more slide. Yes, how far we are with this? So given that the backend stays, obviously it can actually install and do everything. But the UI itself is moving towards something that we could show the public and let them try. We kind of hope that it might be with the next Fedora, like 37. We don't want to promise that because it depends on other things, not just us. So we're not promising, we're just saying we would like to do that. Well, you saw the two screens, so there wasn't too much to click on, so obviously yes. What we have so far is the language, which is like the first thing you'll encounter and the disks because you don't want to destroy the machine with disks if you're so adventurous that you actually start it on something. And these are the most important things. And the rest is just not there yet because we are still working on everything. And the goal is to install live images so that it would be actually a way to install Workstation at first because Workstation, as you know, has the setup from GNOME where you can actually set up users and everything. So that lets us skip these things at first. And eventually it will be able to do everything else so that the backend actually enables. And that's it, I think. I've just said about the Fedora 37 plans basically. The idea is to have a public image but not necessarily have it as part of the official deliverables. So we plan to start releasing images somewhere like on some public space. That will be regularly updated and that people can then use to try out an installation image with the new web UI. But it's not yet about being a part of the good ISOs and live images that are part of the official Fedora deliverables or spins just yet. It's about making it as accessible as possible while not disrupting yet the normal installation artifacts, let's say. Essentially it will be a demonstration of the web UI, not of the whole process of actually installing Fedora with the web UI successfully and to end. We would like to basically install our F37 release time snapshot studio system. Basically it's a tarpaired deployment at the moment. But yeah, the idea, as Rania mentioned, the backend supports everything. So basically the backend supports of course package-based installations. So that's something that we most likely, yeah that will be supported eventually as well and other stuff that we support. Okay, let's see, I think. Yeah, so basically I think I can take over. So thanks a lot for the introduction. I'm not sure, we were not sure if it's necessary or not because some people definitely heard about the project, hopefully. Like how many of you didn't hear about the Anaconda web UI? Yeah, or didn't hear. Didn't hear. Okay, so that's better. So yeah, we were right to do it. So thanks a lot for the introduction. And yeah, so about this event. So this is using the discussion format. And it's basically about that we already did quite a bunch, quite a bit of like some presentations. And actually like, I would say the most interesting part of the presentation was like discussion afterwards. So this is like, okay, let's try something more interactive. And the idea is basically that we have some couple of topics. And we would like to ask you questions and see to get some feedback and ideas. And at the same time have some sort of a structure. So we will basically go over some ideas and questions and topics and we will see how far we get like, which could be. Yeah, please go ahead. I have a question. From developer point of view, why, why do you do this at first place? Like, does it say you work or? So basically, there's a couple reasons. One of them, like we are trying to fix fix more things at once. And, for example, we had some, not the best developer experience with HDK, for example, like we hit some, some beard issues. And it always looked like that it's pretty hard to get like anything inside or anything change in the widgets themselves. And so we looked into how like projects that use the button fly toolkit, for example, work with them. And it looks like they're much more, you have much more resources to respond to projects and they're like working groups where you can get. It's like one working group, even just for installers, like they are like open shift installers doing similar things that we want to do. So that it seems like worth the investment to learn new technology. At the same time, it's much easier to address some of the longer standing issues without like changing an existing UI under users, basically. So now we are working with the long term experience UI designer, basically, and we are trying to do the stuff correctly. Another thing, like the button fly toolkit has design guidelines. That's all the projects, the major projects using it are trying to, are trying to respect. So people who might be using cockpit are more likely to be able to successfully use the installer. Because the current installer isn't actually like built like from in vacuum. It was basically built at the time when GNOME 3 was the new thing, but like it never really like got upgraded or something like that. So by following like using the button fly, it's more likely that we will be able to do something that people will be familiar with from other projects. Like on rail, there is a lot of two things that have similar web UI. And even on federal, I think a lot of people are using cockpit and other tools that are using button fly and cockpit radio technologies. And the last thing is, without going into too much detail, it's remote access that has been a pain point for quite a long time. If you wanted to do a graphic review installation remotely, the only option was VNC, which is unsecure and efficient. And pretty hard to actually use for people in an environment where they might not be able to install like software free like some corporate environments. In comparison, if you do a web UI, like everyone has a web browser, you can use SSL to have it. It is unsecure and it's much more lightweight because you are not doing on machine rendering. Okay, Annie, please go ahead. Yeah, for the VNC, I know that no project recently changed the people protocol for remote access to RDP. If you have, I know that web UI is much easier to use than setting up things for RDP. But have you considered that as an option? Yeah, I've tried to use the RDP on federal statistics and have not been able to make it work. But I know I have noticed the switch, but it doesn't really help us too much. I am not sure, like, I know the limitations of VNC. But the biggest problem with VNC is that basically we are rendering like locally, we are shipping locally rendered data over network. Like with VNC, for example, if you wanted to use it on some limited hardware like Raspberry Pi and stuff like that, you need bigger image, you need more RAM, you need more CPU to just render something on our ARM SBC and then ship it over network. In comparison, we are not yet doing that, but it would open the possibility to have a really small image that just basically has a web server running on it. That opens a web socket through a browser and then you can do really nice graphical installation on our SBC. It really slow everything and it should be much more usable. For example, even with the RDP, it might be more fancy and more modern, but still you are doing local rendering, so you need to have hundreds of megabytes of graphical dependencies and then also render it on. So yeah, that's a good point. We might want to look into that, but it looks like this kind of scraps the whole thing and does it better hopefully. Yeah, please go ahead. Just one comment. I remember when we discussed this 10 years ago. It's your idea actually, I think. Yeah, but one of the motivations back then was it's almost impossible to test GTK. Yeah, that's right. That's a good point. One of the issues and second, things like accessibility, custom CSS and zooming in, zooming out, things like this, you already have that for free in the browser. Yeah, that's a really good point. In GTK application, you are pretty much screwed because... I'm kind of sad about it, basically. It's not that you couldn't do it in GTK, like all you do there. It's just that you really see all the money that has been invested by all the companies that are involved in web technologies these days in action, in web technologies. It's not always going into the good things. Sometimes you see a lot of complexity that might not be necessary strictly, and I'm really glad that we are at the sixth generation of these JavaScript frameworks because I don't really want to even think about using something free, like some jQuery, whatever. It's usable, let's say. And as you mentioned, that's small things, but now we can show logs. If we wanted to implement a log viewer in GTK, it would be possible, but it would be much harder than using button fly or viewer. And then cockpit file access plugins, like 5 lines of code. It wouldn't be 5 lines of code in GTK, I'm afraid. And yeah, changing the text size, you can copy-paste stuff from the web UI because if you remotely connect to it, that's already a pretty nice usability feature, I would say. You don't know what something is, then you can copy-paste it into Google or something. It's smaller things, but it's a lot of smaller things, actually. And about the testing, that might be interesting for someone. Cockpit project is not just this nice web console, they have a lot of tooling and some of the tooling we are using for testing, and they have a really nice toolkit that can do both even-based and pixel-based testing of web UI. So that's what we are using to click on stuff in the web UI quite nicely. You can write this in Python, these tests, and they will interact with the UI in quite a nice way. And there's also a way how to do pixel-perfect testing, which is really useful because you have a whole bunch of JavaScript dependencies that have updates every 5 milliseconds. And unless you want to manually test all of these, a really good smoke test is to do these pixel tests. So if you get a new React or something on Buttonfly, you can check if it changed the layout of the resulting web UI. It's a really good smoke test, it's not totally broken with the update. Regarding user experience, are you collecting some approaches from different installers, from different distros, are you somehow inspiring by them, combining good things of them, for example? Yeah, we are definitely looking for that. Not really just pick and place ideas, but one thing we are looking into is also, let's say the viewport. With the web UI, we need to think more about browser window, for example, because that could be really dynamic. Again, Buttonfly, they say it's reactive, I think, or responsive, so basically it can scale the UI elements as necessary in most cases, so it helps with portraying those, or with mobile devices, but it also handles most of the cases where people change the viewport all the time. But at the same time, the problem is we need to support remote access, but we also need to support local access, and you might have noticed the trend to have wider and wider screen monitors. One thing that we are at the moment looking at how other installers handle is this, basically, if you have this 21-10 monitor, how do the other installers do it? What we are looking into that we might want to locally do is a constrain viewport for the installer. So basically, we keep some same aspect ratio, and basically if you have this big monitor, you would have something that's still usable and not like you have the wizard step changed there and then done somewhere, and then either lots of white space or... So basically, this is something that we are already actively looking into other installers. Yeah, please go ahead. Well, I'm just remembering the first or second slide where you have the screen, and you have the button at the down back, forward or next or back. Well, I have an interest. Is there any convention? Because in the Linux system, each application has a different order. I mean, yes, no buttons. You know, it's on the one side or the left side or another side on the opposite side. Other distributions like Windows, it's more convenient to have it in one order. I mean, is there any recommendation on how to design such a button in which order? I think we are using the defaults of the button fly for this. I think Butterfly has this and we are just expecting that. I was literally just looking at the pattern fly design guidelines for the wizard and they explicitly spell out the order the button should go in. Perfect. That's also why we have a designer on the team, so I'm sorry, I can't really answer that. Let's go ahead. I know that current Anaconda installer has agreed for partitioning disks, which I found very convenient, apart from the manual partitioning. I don't know if that application is just that there is some library at the GTK front on top of it, but will the web installer have something like that using that library or how will you exactly do the even more advanced partitioning? Yeah, so basically just how it actually works at the moment, like the BliBliWet GUI, this is basically like, normal Anaconda uses the BliWet storage library for storage modeling, basically, because what Anaconda does, that's kind of different than many other storage management tools. We basically scan the storage using the BliWet storage library and then we apply the actions either from like kickstart for automated installations or what the user will input what they want to do with the system into the model. And then we have a reasonable chance that this is a storage layer that can be created. And then only after we are sure that it will work, we will kind of commit the model to the system. And BliWet GUI is a graphical user interface for this library that can be also used as a standard application on Fedora. And this is in the current Anaconda. This is a GTK, Python GTK application and this is basically embedded as part of the current Python GTK interface. So basically, this doesn't currently have any like web interface for itself. It's not something that you can like one-to-one use in the web GUI. But basically what we are looking into at the moment is that we will definitely continue using the BliWet storage library that is the backend for not only Anaconda but also for the BliWet GUI. So the power of this technology will still be available then. But we are still looking into the details like how it will look like. Like one idea we have at the moment and we are still investigating it's not decided that it will go like this is to use BliWet for the let's say like guided or profile-based partitioning. We would like to make it much easier for people who want to do like the often used cases like wipe all the data and reinstall. That's easy. Or I have like this Fedora install or whatever it be possibly install or something and I want to use my home folder. Stuff like that. Or even, yeah, resize my windows installation and put Fedora next to it. Stuff like that. This is where the BliWet storage modeling is ideal. The same stuff is for Kickstarter-based installations. That's also based on BliWet and already it's really useful that you can basically say people like yeah, this Kickstarter won't work before you vibe their data. So no change there. But what we are looking into that might be an interesting option if it works out, which is not yet clear is basically we are looking into possibly using some existing storage plugins in the installer and one of them that we are looking into is the cockpit storage plugin. At the moment it's pretty simple but we are thinking that possibly we could do the manual partitioning using the cockpit storage plugin. It would be a departure from what we have now because that won't be using BliWet. That would be using like direct changes to the target system but on the other hand like we are thinking like we will need a pretty complex interface for web interface for storage manipulation. Cockpit already has quite a complex not yet that supporting all we need interface for storage manipulation. Maybe we can like cooperate on development on this and have the manual complex do-it-yourself partitioning the same as in Cockpit. Maybe extend it so the Cockpit users will have more support for more technologies. At the same time we won't be implementing yet another manual partitioning interface. Like we would implement the installation specific profile based BliWet using partitioning and use the Cockpit plugin. Maybe we will see. That's an idea we are looking in if it will work. So that was comprehensive. I'm sorry for that. Too much information. Thank you. Yeah, please go ahead. I have a question. You said that it's going to be something like a wizard and I would like to ask just will it be possible to jump back in that wizard and will it remember all the changes I have made before I went back? Yeah, I think the idea is that basically you first need to visit a screen but then you can use the switcher on the left to get back to any screen. Like this is the idea. We are already aware of some issues with like optional steps and stuff like that. But that's the general idea. You first need to go to this screen but you should be able to get back and that's kind of also a specific thing for the web UI. The current GTK interface was very, very stageful. Once a screen is loaded, it's always there. It has some data. We need to make sure it actually ends up in the backend. In this case, we need to handle stuff like people reconnecting to the web interface remotely and refreshing the page. So yeah, we really need to work with the backend data anyway. So that should not be a problem, hopefully. And then I have another question. It happens to us when we tried to squeeze the windows partition a bit, especially with Windows 11 that we somehow triggered the BitLocker and then it wasn't very good for the Windows user. Will you address that somehow or? It's kind of a thing for the underlying technology. As I've mentioned with the profiles, the stuff that the computer can do automatically, we would like to make it accessible. So this is something where we can ask questions and people will say, do it or something like that. But this is really a low level technology question. We would have the same issue with the GTK interface, basically. Please go ahead. Do you have any questions? I have, but I see that it's one minute past four. Do we still have time? We have one hour slots. Okay, cool. So I actually noticed that you've mentioned that you have a live CD installation supported, right? Does it mean that you can run it on the live CD and then deploy that image or you just boot the installer which dumps some sort of pre-configured live image? So what we have now and what we will release in the F37 timeframe is effectively boot ISO with the similar level of functionality as the current federal workstation. So it's live CD. We call it a minimal viable product. Okay. It's thin because basically the idea is that the next step is most likely to be an actual live CD that uses instead of the GTK interface uses this interface to install because it's not really that different. What we have now is a tarball that we will unpack to the system. In the live CD the change is basically that instead you mount it only a base layer and then dump it into the system. So let me tell you why I was asking because I see that it's more and more popular to just dump some pre-configured image on the drive and use ignition combustion something that will configure it on the first boot and we are trying something similar with desktop now on leap for example. And you guys have something like that for pre-configured images as well. It's not exactly live CD but it's almost like dumping a live CD. It depends like how what additional steps you need. This will do the storage and then it will dump files on it. Yeah, exactly. The only reason is the only purpose is just to dump the image. Do not even ask user any questions just dump it. We have something like that, like very minimal wizard and I feel like this this can be more and more more and more trendy even on desktop for OEMs and stuff like that. Yeah, this is kind of like an artifact of us wanting to have and installations as easy and as simple as possible before. It's already was not easy to bootstrap it all. That was really nice cooperation with the cockpit team. We actually had a person from cockpit for a couple of months working with us for time to get it all bootstrapped. Okay. So that really helped us to get going and it really helped that also that we decided to start with limited amount of features at the same time. Yeah, let's go ahead. Speaking about cockpit and you mentioned it already are there any plans to reuse the screens that they already have to somehow maybe cut them off from the cockpit back end and hook them up to the Anaconda back end instead? So basically that's the thing about the manual partitioning. So the idea that that's one of the candidates like actually we talked with the cockpit team and mentioned like, yeah, it's like we have already a plugin and this would be another plugin with a valid work and the reply was yes, it will. And if there are like three ways how you can do it you could like switch to another cockpit or something that doesn't fit that much or you could use it basically as a black box. So like you do just take the whole plugin and put it as a step into the interface that would work and also that's more involved for actually the structure of the plugin itself you can basically take these like parts of it. You can kind of like see in the cockpit screens that it's kind of some like some boxes or something like that. I think you could do it at this level. You could like take these bits of it if it's correctly built and then you could embed that in your web application in random places basically. So some sort of this, we are looking into it in definitely the storage and possibly even like networking because already we are building pattern fly interface for a cockpit plugin essentially. So it would really make sense as you mentioned to kind of share the code and if we can work this out even if we like had to address their concerns and they address ours it still makes sense to just do one thing and use it post in Anaconda and in the cockpit interface. Because they already have many things, right? Like they have user creation, root password you can start and stop services you can configure firewall, whatever so it would be best that if people could just use the same screens in the installer that they have in cockpit but instead of configuring the runtime of the installer they would configure the installed system but they would use the same screens. Yeah, it might not work in all cases like in many cases it's talking to live system the bus API and it would require big changes and the screen is possibly like there are some considerations why you would want to do it differently in the installer but especially with some screens already it makes sense. When you are already manipulating storage you can just tell it where you want to manipulate the storage Instead with the users for example it could be more involved that you don't have the system or you don't have the system yet so it might not be that easy to kind of emulate it or something but in other cases it's totally fine totally possible on a technical level and we hope it will work out. But you could provide the same D-Bus API, right? Like in some cases I think we still need to get the data effectively like before we start the installation I'm not sure about the user I kind of think that we might need to have the data before we actually create the system so if it expects to be talking to whatever user creation demon over D-Bus it could be problematic. Well if you provide the same D-Bus API then you can instead of create it I don't know if you can fake it like this Yeah but then you will model the host preparing before it will be created Yeah that's a good thing It might be more work than implementing the new UI plugin One thing is that for example for the users we still haven't got any real lot of requirements to support all the complexities of user creation on a system where you already have other users and all the specifics So we are thinking that some simpler user interface to just create one user or the things that are really necessary to be done at installation time may be better than to support Maybe it could be too complex or something like that We had also some questions for you so That's another thing Maybe people won't ask so we created a whole bunch of stuff but I think we can skip some of those or maybe let's see This is more abstract but let's get some answers I would like some of you to say how would you like to imagine the ideal installer Please go ahead Yeah I was thinking about for example if I needed for a specific case let's say a company wants to have their own images and for example they are in-channel setting up some specific stuff and add a plugin to the install itself and make a new step in the wizard where you could add some stuff To that Yeah I think that's a good answer for this and I would say that this is planned basically already in the Anaconda interface you can add plugins either like just like something that's part of an automated installation or even the text interface Anaconda has a text interface that's not influenced by the web UI project at all that will stay there and you can add GTK Anaconda interface I don't already and we definitely want to keep this in the web UI as well so basically it will be a cockpit plugin as well so that could actually make it more accessible to people because I think there are definitely much more projects creating cockpit plugins than there Anaconda I don't it's totally different for the Anaconda at the moment it could be much more similar to just another cockpit plugin that there are quite many OK so thanks for the answer that's good good idea I think any other like what would you do if you wanted to create an install you have more questions so I think yeah please go ahead on the same topic I feel in many cases it's about having a good balance in between steps before and after the installation for desktop you probably want to do more after for server probably more before so having you know realizing the balance and tweak it for the use case would be really good yeah my my comment for that is we will definitely need to handle that and we kind of handle it right now you also use no munition setup right for the user part basically on the federal station there is like two screens and the rest is via no munition stop on the other hand on rel there is like 15 screens and no munition setup in many cases that is expected right but already this is something we can handle better like that's one of the ideas like with the stuff we can much easier much more easily pack a lot of screens there and at the same time if you don't have like 15 screens it doesn't look that as stupid as it does now when you have like just like these two small status icons for two screens on a huge screen they even mentioned something that we do that may be interesting for you so after the no munition setup we even have like I think it's called what's first blue which installs like non-rpm content after the user logged in like flatpacks from fathub and so on so I kind of find it really cool for this kind I have one idea but maybe this is already known have you perhaps considered that people could record the installation process and have a kickstart file created so that they could reuse that same installation process on other machines so that's already there from like level 6 or something or from like but not on Fedora so basically any Anacronica installation creates a kickstart file describing the installation and it's stored in the slasher root holder the only problem is that it's not like something that's let's say you are integrated at all and it's most in many cases it's not like 100% the same like you usually should like take the file as a template if you wanted to do it on a different hardware like the partitions might not fit and stuff like that it's good to like read it at least once before you try to install the machine again from it but it captures all the configuration but if I don't know about this then you don't know you need it so but yeah with the web UI what we could do and what we thought about as an idea but we haven't tried to like implement it you can much more easily like paste stuff into the remote interface especially so we are thinking that maybe you could like export this file much more easily than with the current interface possibly you could have some sort of access to it so you can like copy paste it out instead of phishing for files on the system possibly even the other way around like open a window put the kickstart content in it that could work so when is the kickstart file actually generated could you give us a quick show it in the UI for example at the moment it's written out at the very very end of the installation but I think by the time you are able to press the begin installation button it needs to be basically stable I think it doesn't change after that so technically I think we should be able to dump it at any moment and if I had the kickstart file ready and I would load it into the Anaconda would that affect the wizard so that I could make changes in the wizard I'm not sure I want to really commit to that because there's a lot of data sources that can influence the state of the back end so at the moment I'm not really sure I want to really totally 100% commit to it as a stable supported functionality because you already have the data on the system, you have defaults you have the kickstart file so once you already did it once then kind of reloading it it's not that simple I don't think reloading it but I thought like I have a friend who is a total newbie so I performed the installation for me once and then I just distributed the kickstart and that's basically automated installation they would just make some changes in the Anaconda before they did the installation which perhaps would probably show that there is a conflict in storage for example or something like that at the moment what you are basically describing is like partial installation where you have a kickstart it's not complete because the logic currently voids in a way that when the kickstart is complete the installation is started so you need to have incomplete kickstart so it doesn't start the installation and you can pre-configure the interface and it has a lot of issues at the moment so we are looking in two ways how to possibly do it in another way or do it better or something like that how do you remember maybe once to mention something there is an issue and that issue is that with the backend you can with the kickstart easily automate the creation of the kickstart and to write kickstarts that have a lot of information in them or scripts possibly even and you can't exactly with the user interface you won't have a person typing in a python script to run after the installation is complete so there's what's it called? Disparity between these two things what the UI offers and what the backend offers technically and it's very easy to get into the situation where the kickstart for example describe 15 users to create but the UI supports just one so yeah that's we have lots of stuff that support it only in kickstart and that's kind of on purpose like it's not really it supports everything in the interface unfortunately so I think there will always be some mismatch between what you can do in the kickstart on the other hand I understand that's something to discuss I think definitely if you want to talk about that we can meet about that or we have some communication channels we have discussions on our GitHub project we have mailing lists I have it in the slides later on so let's go to the next one let's see what we have here I'm not sure this is a good question right now because like I'm not sure what the third one is actually automatic yes that actually reminds me of how we get the user request and how we need to interpret that yes so basically how many of you have done an automated installation that's actually I think a good question like we've done on the right yes do you know that it's possible we have done it and you too that's all really like do you know what kickstart is and have you have you used it for an automated installation yeah once and twice maybe I think we need to make it more more accessible so basically it's about making the installation fully automatic you have a file that describes what you want the system to look like and then you configure Anaconda to boot and to load this file most likely from an HTTP server or even you can include it on an image and then everything happens automatically and you reboot into the install system I think the biggest user of kickstart is Beaker we also satellite this using it for machine provisioning and yeah it's like it's the few people who installed the most machines most likely they are using kickstart I'm checking with the web interface if you are actually using the browser as the UI or doing it remotely you could in theory highlight this option more and maybe ask for upload of the through the UI that wouldn't be possible in the GTK because you would have VNCS that wouldn't really work VNCS some support for copy-paste but it's not very dependable I would say in the web UI really that's a really huge thing I think that you can work with text, you can copy-paste and it should work always as long as you can connect to the machine it's just a web application so it's all text and you can like copy-paste or like some weird behavior you just copy-paste the stuff out of the installer and as you mentioned that's something we thought about that would be really nice because like one of the first steps would be something like that it would be like input kickstart you place it in but yeah we still have issues that Vladimir mentioned so if you can fix those or somehow solve it please go ahead what's the plan for authentication that's actually not easy at all definitely encryption is nice that we can definitely do it but like how do you tell that you are talking to the installer because like yeah you have SSI certificates but that's for a domain you have the same problem that you have with household routers each of them is on some random AP address or some like automated awahi whatever DNS and like how do you know that you are talking to the router and not to a hijacker on your network somehow so that's problematic so like we can definitely encrypt but how do we keep the chain of trust somehow that will not be easy another thing is like how you authenticate like even if you somehow accept a self-signed certificate or something or even just do it over HTTP because whatever then that kind of drops one of the benefits of the remote access to the API unfortunately another thing is like how do you handle passwords let's say so one option is basically that you need to have physical access to the machine then we can show you like fingerprint of the certificate and the auto-generated password that's most likely one of the options another one is that you just basically like put the password in somehow like kickstart or even boot option like it still means you need to have physical access to the machine or you need to pre-configure the machine to boot into the image and another thing is that I'm not sure any of you heard about the image builder project perhaps? Composer Composer image builder it's basically dependent I think a composer is upstream project or basically image builder is deployment or something like that it's a project that aims to make it much more easy for people to build images both images that you would deploy in a cloud and installation images so one option could be that you basically like create your own installation image and burn in your certificates and whatever authentication tokens into the image and then just boot it so you won't have to fudge with like any boot menus or whatever and the chain of trust is handled by you because you're burning trusted certificates keys and stuff into the image and you could even do this make the image connect to your infrastructure somehow like it could connect to some like jump host and basically like tell you hi installation has started I'm on this IP address and because you input certificates into this image you will know yeah this is really my image talking to me please go ahead if you create your own image isn't it just easier to deploy it rather than go through configurations that's if you already invest into the creation part like if you can make it either generic enough or your hardware is the same then you can pre-configure it to do the installation for you automatically as well one thing that I think Frantha from Federal Accuade suggested is basically if something goes wrong then you can activate this if something goes wrong then you might be able to much more easily investigate what went wrong because there is even a terminal emulator web-based terminal emulator component for cockpit there are log viewers so it might be much much easier to debug automated installation issues if you can easily connect via web interface to the stack and then to try to somehow find out what went wrong but yeah that definitely on the other hand still we do image build I can imagine cases where you are like a campus admin and you have people install like start students installing their laptop so you kind of like pre-configure it so they can easily or you can easily help them for example when the installation gets stuck or something there are options but like definitely hopefully it will be better at the end like the lack of any authentication options at all even though like IDP maybe could be better but I think like one big benefit is one big benefit is that you just you don't need the software like even with the IDP you need to have an IDP client installed like you could do the installation for your mobile phone like usually you would have to install an IDP client on your mobile phone and I'm not sure how well it will work on the screen what else do we have there I think we kind of covered this like that's definitely something that we will have to have somehow both in amount of screens and also as you can think about like yeah input the kickstart into boxes is perfect but like apparently half of the people there haven't used kickstart to do an automated installation so if we put kickstart there like we don't want to confuse people who just want to install their first linux laptop on the university or something on the other hand there are good reasons why you want to do like openscap profiles and configure S390 storage in the interface like so this is something we are looking into definitely and I think we I'm not sure like what how to handle this I've seen a lot of solutions like basic advanced mode but I'm not sure that's definitely a challenge so okay this is kind of an interactive thing and we are over time but there is a coffee break so like if people don't want to get a coffee in the next five minutes we can do this one so we haven't shown you like one of the screens actually and this is a screen that is the final screen before we start the installation that's that's new because the spoke with these miniatures showing you the available screens in the current UI that was the last screen and the first screen as well now we have a screen that capitalizes what you can do with the install so my question is what would you expect to see on this screen how should it look like please go ahead if I take experience from other installers like Jast they pretty much show just some details about it yeah they even provide advanced features like clicking on them, change it from it again as far as I know and change some details but I think one of the most important thing would be disk partitioning because that's thing when if you do mistake you are going to regret it mostly so I mean I highlighted maybe some images about the disk layout which will be there because that's a good representation of that somehow how do they put so much information on the is it somehow like expandable or useful? yes it doesn't do it but I think Kalamaris does that they are small like wow if you have this kind of partition then what will happen yeah I would highlight that you mentioned that they make it possible to like go back to change it that's something that we also have been thinking about because like if you have many steps that we already do enable you to go to back to let's say arbitrary previous step but this is easier like with which screen does this whatever SCAP thing I want to turn it off and never see it again or or on the other hand I have noticed I have no SCAP profile like I will like yeah my company will end if I install this machine without a SCAP profile so I can go easily to the SCAP screen when clicking on this yeah any other suggestions? if it's a wizard won't the screens that go after one screen be dependent on the previous screens that's one of the problems we are looking into like if you have like let's say you have the package installation stuff so source and then that's something we are looking into at the moment that we will have to be creative about this at the moment we don't have that so it works but we will have to handle it somehow go ahead if you would go with the summary as the last screen then technically it could be also your first screen if you would start with some defaults I know the user will not be creative will not choose the name but the first would like dominate the stuff technically it could be the same as the first so basically that is actually a good point basically that's about defaults like this what we do is simple but it actually does a lot of stuff using defaults and those are not visible at the moment because so basically this is how it looks like at the moment it's kind of it doesn't have all the things it has storage but it's a really simple storage it doesn't show you the layout for example but that's definitely something that will have to be extended it's not that possible to click on stuff to get it back to the screens but we are considering that it doesn't have a scroll it's not that visible now but it does not scroll so this is all we have now but I agree about even the visualizations that's a good point I think but somehow we might need to have like collapsible sections but that's the thing you don't see like network NDP or something on configuration there even though we definitely used some default value to set it up it boots so it does bootload the configuration so that's another thing like if we put there some value we need to make sure that people know that this is if there is no screen to configure that's a problem so it's a question like if we should put there the default values until we have the screens to actually configure them so that's another problem we are looking into right now and let's go okay so this is another like the second interactive stuff and then I would say like we are over with the mandatory stuff for this talk so okay this is the let's say last screen of the install and basically we are looking into some options how to make it look and basically the previous one that was the review screen and you create the begin installation tells you it will destroy all your data and you need to agree and then you get into the installation progress after this you can go back actually like after when we start to destroy your system then it's no way it's no reason to go back and we are looking how to make this like make this look nice with the limitations that we actually don't know for many of these steps how long they will take like when drag would start generating around disk when some of the payloads are installing we don't have any progress reporting on from shortly also some of the stuff can depend on external factors like networking so sometimes it can take 5 seconds sometimes 5 minutes and sometimes it can get regularly stuck I would like to make it easy for people to actually like notice that as well and report the issue for example so basically we have like 3 variants please go ahead yeah with the installation progress well do plan to add during the RPM installation additional information first of all yeah we have information for RPM that's fine but we don't have for example like the interim this generation takes random time yeah sure I'm not talking about the progress but to provide the additional information what's going on because sometimes you get some messages from during screw plat and so on yeah maybe they can be quite important so unfortunately I don't have this on a screenshot but I think I can I can show it like in a minute actually and basically a demo of the interface but would we find out that there is a really nice log viewer component in pattern flight that can show you logs but also are a bit ready like structured information so we are thinking about using that to provide more information for the stuff like package installation for example it looks like an ideal candidate yeah I ask because I compare package kit offline installation with the system upgrade from the DNF and from the package kit you've got only progress from the DNF if you want you see well what's going on and also you can see the output from the RPM if you like and my question is what is better for the users for debugging it's better to have like this structured data if it ends up in for example maybe it's enough to make it easy to access the journal and to get the data from there maybe it's again like basic advanced but what is confusing for some users what is like necessary for others I see an error it's difficult to display the last thing that was happening because the user can only read logs if the screen is responsive right what if the machine is stuck and see what was the last thing that actually was happening you mean like if the machine totally like closes bad something underneath is frozen then you are basically stuck with what you see here which is not much right actually that's the nice thing about the logs if this is running like it depends like this if we are running it locally in the webkit webkit view like gdk application that is showing webkit view window full screen or remotely you will have at least this and you can like highlight stuff from it maybe you could even have like some local cache of the messages or something you can if the machine dies then yeah now it's a very important and interesting question well maybe not question but a problem what if the installed machine gets stuck but what if my machine gets stuck if I use like remote installation and my machine gets stuck so nothing happens to the installation basically right you should be able to reconnect from another machine but how do I know which is well I know that my is stuck but I think it's important that the user still sees something because it confirms that the installation is not stuck you mean on the local machine when I your machine dies then when I perform the installation either locally or remotely so I need to see that there is something happening on the screen because sometimes it stops responding nothing is happening how do I know is it stuck or is it not stuck shall I still wait this is problem and like one thing like showing you that like if your kernel is still alive locally is basically the spinner that's actually really nice thing like this is not a GTK spinner so it doesn't consume 100% of your CPU it consumes less but this tells you that your browser or your webkit view is alive enough to animate the spinner so that's one thing but the other one is basically when we have it we will provide the more general data so you know that something is happening and also we want to provide like some sort of log access or stuff like that because like if you are advanced user and you think it's stuck you might be able to find something out from the logs I'll show you the log we already know I basically just wanted to ask like really quickly we have like three versions of this so we have this one one that is more colorful it basically shows the progress more with colors and then one that's totally simple so I will just go very quickly about them so this is the more complex one that is the complex but colorful and that is the one really really simple version and I would just want to ask you like raise your hands let's say which one do you like the best so who likes the more complex but not that colorful one that's like one, two, three, four five, six, seven, eight nine okay it's nine for A who wants who likes the colors one, two, three, four five, six, seven, eight, nine like eleven or something that's why I'm a war and who likes to have the least amount of information okay so that's just one it's surprising you have like really advanced users there and they want more information so basically actually this is what we have now and we are most likely to use something like this like one of those two so this is actually what we have and people mentioned they don't have enough information on the screen and yeah that's done I think we discussed most of it so basically okay so basically yeah if you want to get involved in our we are going most likely to run some usability studies in the future and this is basically the first one is a sign up link when you sign up there so I would hope this will be visible in the recording and hopefully the slide will end up somewhere on the conference page so if you want to get back to this or there is like some short URL and basically we will reach out to the people who are interested in trying out this new interface if they sign up there and most likely some of you might have already seen some emails on like Ferrad.fl where we are looking for people wanting to participate in these usability studies so basically that's also why actually some of the raised points I've heard that people say that but just a small subset of that we already I think we have really good feedback from you today so thanks a lot for that already and this is like our mailing list basically like again good communication channel to reach out to the team and this is basically like the structured questions we had it's clear over time so I suggest if you have any more questions please go ahead and what I will try to do is do a really quick demo that wasn't really planned but I'll do it anyway so any more questions okay that is my question okay try this one okay this is the correct screen okay so this is the this is actually the Anaconda API live and running on some AVS through AVS instance and yes it's really nice that you can do stuff like resume or you can like this is really nice for debugging for developers but I mentioned this is really hard to do but about the the log viewer so what we have is this this is like some dump from a log file but I think you can kind of get the idea like we can use this element to show any reasonable structured data and it already does like type to search and stuff like that so basically what I mentioned is yeah we have a package installation log somewhere already so that could be one of the options you could have like tabs or it could be an action that you when you install the NF payload you could have some like show me more information you click that and you get this model window with the data about that there could be all the messages that fly past when you install could be in a log file and you can see them there to check everything is fine stuff like that and yeah basically very very quickly what we have now you have seen it already this is the second screen slide some discs you check it it looks fine I think we add some more time there to actually show the spinner sometimes it was too fast this is the review screen and this should show you the scary scary dialogue that will erase all your data because it will and this is the current current progress screen it's as mvps you can get it basically but still you have this the wizard model you can put more screens there as Raja mentioned it's scalability is still something we're looking into because there can definitely be dependencies between screens like some stuff might need network before you can interact with it if you select a different installation source then it should drop the selection screen if you switch to OST or whatever and again like if you input a kickstart and then you decide to change the kickstart or something the dependencies is something that was kind of handled in the happen spoke model but not very well on rel you need networking to use the rel cdn but you have spokes that are next to each other so how do you know where you need to go to set up your networking you don't so it was not a good user experience already so can you show the logs are they live so basically the logs are live but the file never gets updated so unfortunately what they can be definitely I wanted to show the syslog that there is a syslog file that I think it gets updated live but I hit some limits on the file size in the cockpit tooling so I was not able to handle that that easily you can basically run arbitrary binaries using cockpit on the target machine like the tooling for cockpit is pretty pretty nice and you can all use this for tests so basically you can execute random commands on the virtual machine where the tests are running so it's the same stuff it's pretty pretty powerful and nice to use so the plan is to basically run some get or whatever on the log instead and then stream the stuff there I think that's the limitation of what was mentioned on the DNF talk of like how much stuff you can move over the bus because this is running over the bus of course from the back end to the UI we are at the end of the coffee break perfect wish there is our captive audience ok that's all thanks for all the feedback it was really nice and we will be somewhere if you still want to ask more questions and sorry for using up your coffee break I hope you like it