 So, we are going to talk about creating your own federal images and pushing them to cloud using OSBuild Composer. Andrzej, can you display the next slide? Okay. So, first of all, I would like to introduce the project that we work on. It's called the OSBuild project. And we focus on building tools that you can use to create operating system images. So, for example, if you want to create default images for your distribution, or if you want to create a customized image, again, for example, that contains an HTTP proxy for Amazon or just a simple QCOW image with some pre-installed software, OSBuild Composer should be the right tool to do this. And OSBuild Composer itself is based on tool which we call OSBuild. We presented it last year at DEF CONF, and you can see a link to the presentation in the slides. So, I will just briefly explain what it is about. So, OSBuild is a very low-level tool. It takes very detailed machine-readable image description, which is just a huge JSON file, and it produces an image. Now, what makes the difference from all the other tools for creating operating system images is that we want the image to be well defined, and we especially want the image-built process to be reproducible. So, that's why we created OSBuild in the first place. Now, because OSBuild is a very low-level tool, it's not very user-friendly, let's say, and it's also not meant for end-users. That's why we created OSBuild Composer. Some of you might remember Lorax Composer, which was the tool for creating customized operating system images in Fedora, and we created OSBuild Composer as a drop-in replacement. This means that we provide the same REST API as Lorax Composer did, and so you can use the same client-side tooling as you could when you were using Lorax Composer. The difference from OSBuild is that now, instead of writing a huge JSON file, you simply define customizations that should be applied to the default distribution image. This means that inside of OSBuild Composer, we define what it means to be a default Fedora image, for example, and then we apply these customizations to the image so that you can get the image you want. Next slide, please. You can see an example of such customization here. We call it a blueprint, and it is a simple toml file, and in this blueprint, you can specify, for example, a new user that should be present in the system, or a package that should be installed, or a system deservice that should be enabled, and then when you have the blueprint, you can apply it to a distribution and image type. So, for example, if you want to create Fedora 33 image for AWS, you would select the distribution and image type, and then apply the blueprint. And now, Andrei will talk about uploading to cloud. Okay. So, this is the huge advantage of OSBuild Composer in comparison with the old backend, because OSBuild Composer can not only build those images, but it can also directly upload them to cloud. If you wanted to do this manually, this was very tedious, and the APIs of all cloud providers are different, are often a bit weird. So, we did all the hard work for you, and OSBuild Composer with the same process images to various clouds. Currently, we support AWS and Azure. And just this week, we merged support for VMware, shoot out to Joseph that I saw in the audience. So, yeah, this is how OSBuild Composer can really help you to easily run instances from your customized images in clouds. I think that you are now pretty hyped about our project, and you want to try it. So, how to use it locally? You have two options here. One is graphical. The second one is in terminal. Let's speak about the graphical option first. It's actually an application in Cockpit. It's called ImageBuilder, or the package is named Cockpit Composer. And you can just click around in the GUI, add packages, add users, whatever you want. And then you can just use a simple wizard to upload it to AWS, Azure, or VMware in the future. So, yeah, it's very simple. You can just use your mouse to do everything. And I think that even your grandmother can do it. And for the CLI, if you want to feel like a hacker or you want to automate it maybe, you can use the CLI client called Composer CLI. You can just push a blueprint in thermal format to Composer CLI and then run some commands to upload the image into cloud. But let's not talk about theory anymore. Let's go to the demo. The first demo is about the ImageBuilder application in Cockpit. We will use it to build a custom image and upload it into AWS and verify that it would it. So, let's run it. Okay, so let's start in the Cockpit console where I can open the applications. And I can very easily install the ImageBuilder application. Once it's installed, I can open it. I need to enable the ImageBuilding service. And now I can create my first blueprint. Let's name it demo. And, yeah, on the screen, I can add components or packages into the image. For example, I want an HTTP server, so I can just search for nginx. And after a while, I can click on the plus icon, an extra nginx, and it's selected. I can also review all the dependencies that got pulled by nginx. So these are all the packages that will be installed. When I'm happy with the package set, I can just commit the changes. And that's everything with packages, but I want some more customizations. For example, I want a user in a predefined image. So I can just fill this form with a user demo, which will be administrator. I will add a password. Please don't do this in production. That might be dangerous. And, yeah, now I'm happy with customization, so let's just build an image. Let's select AWS Image because I said that we are uploading to AWS. I will check that I indeed want to upload. I can choose an image size. Let's use 10 gigs for this demo. Why not? On the screen, I need to enter my AWS credentials. They are not shared with anyone. They are just used locally, so we can upload the image into your account. Now I need to fill some more details, like image name or AWS region in which I want the image, and S3 bucket, which is used in the process. And that's it. Now I can just review the values, click finish, and the image build and upload process will start. In reality, this can take 10 minutes, but this is a recorded video, so I cut some parts out. But, yeah, the image is now uploaded, so let's verify that I indeed have it in my AWS account. Let's open the AWS console and let's go to AMIs. That's Amazon Machine Image, I think. And, yeah, my demo image is here, so I can just launch it very easily from here. Let's use just some same defaults. Now AWS will ask me if I want to insert a key pair inside the instance, but I don't want to because I already created a user in ImageBuilder. Okay, and it's now running. So I can just copy the IP address from the console and head straight into my terminal and SSH into the machine. Yeah, now it asks for my password that I inserted before. And let's make sure that it's Fedora. Yeah, it's Fedora. Is EngineX installed? Yes, it is. So yeah, as so, this is a very simple way to build your own image with your own customizations with your packages and upload it to cloud. If you do this a different way, it will take you more time and you have to work with Azure CLI and AWS CLI and all that stuff. But we just made it possible in a web browser. So yeah, I would say that ImageBuilder really makes your life easier. So Martin, are we ready for your demo? Yes, we are. So in this demo, you will see exactly the same but using command line instead of a copy composer. As you can see here, we again define a blueprint this time as a Tommel file and a cloud configuration. And this time again as a Tommel file instead of filling the form in cockpit. Now before you can start to compose, you need to push the blueprint into the running OSBuild instance. And now you can start to compose. So here I display the help text for the compose command. And as you can see, we will need to specify the blueprint, the image type, which in this case will be AMI for AWS images. Image name is the name you will see in AWS console. And finally, the cloud profile, which specifies your credentials. And yes, so you will type composer CLI compose start the name of your blueprint AMI, then the name of your image. And finally the cloud configuration file. And hit enter. Now OSBuild is processing the request. You can use compose status to monitor the status of the running compose. And again, it will take at least few minutes, maybe a few hours depending on your internet connection. Well, I have a DSL connection so it took me like three hours. Yeah, so back to you on Jay. Okay. So I need to jump to the next slide. Okay. So what's the current state of OSBuild composer? So it's already available in stable Fedora. So you can just install it right now if you are running Fedora. It's available also in rel 8.3. So you can build your own rel images and upload them to clouds. Also, we've just merged support for building CentOS stream images. So if you want to have CentOS stream and AWS, you can just use the image builder to build them. This will add soon because we've merged it like this week, I think. So yeah, stay tuned for this feature. So if you want to try it right now, just type DNF install cockpit composer and it will pull all the dependencies like OSBuild composer and OSBuild. And it will be just fine. And yeah, open the cockpit console and you can just build your first image right there. We have a new upstream guide, which is very cool. It has some information about what you can do in blueprints, how we can upload these images. There are some technical stuff. So this is very nice. Like this is a month ago we did this thing. So it's pretty up to date, I would say. We have, of course, a GitHub account with discussions with issues. So if you have anything, if you feel like we are missing a feature, just go there and tell us because we are interested in what you need. And I saw already in comments that some of you are interested about OS3, comets, images or what these things are. Yeah, we can build them too. So there will be a talk about building federal AOT trees at 5pm today in session room 2. Martin with Christian will be speaking there. So go there and see it. Federal AOT is like to think of the future. So go there and see how we are assembling those images. And this is pretty much everything from us. Thank you for your attention. If you have any questions, just use the QA panel in Hopin. Or we can just hang out in the Discord room afterwards. If you don't have any questions, just go install a cockpit composer and try it because it's awesome. And yeah, that's it. Thanks. Thank you. Thank you, Henri and Martin. Actually, there are a lot of questions. There are a lot of questions in the chat and also in Q&A section. So I'm not sure if we will have time to read all of them, but for sure you can move to the chat room and talk to our speakers in the session. So I will start reading questions. Mira Slavt asked a lot of things and I'm not sure, but probably already answered in the chat. How far is a C build supporting Ansible for doing some of the setup? Yeah, so thanks for the question. And I will repeat the answer. So you cannot actually use Ansible during the image build. It's because we don't actually run the system. We operate only with file system trees, whereas Ansible needs a running system. So what you can do is to include your playbook and run it during the first boot. Or you can rewrite the customizations that you have in Ansible playbook. And you can rewrite them to Asbuild Composer Blueprint. Thanks, Martin. Next question from Marcin. How well a C build can handle custom kernel and dropout models as humans that they are already packaged as RPMs? Yeah. We did some work in supporting alternative kernels for IoT. So that should definitely work for the IoT stuff. I'm not sure about like regular images, but it should be possible. I'm just not sure if it's implemented. So I need to look it up. Yes, if I can add to this. So the screen allows you to specify additional RPMs and also to specify additional command line arguments. And this is definitely implemented and already available in released Asbuild Composer. Dracoot, we don't actually support any customizations here. We are currently just using the default setup that Dracoot uses. Okay. Thank you. Next question is, can you include both pre-profile support for the uploads? That was from David Tunga. Jose, do you want to answer this? During the presentation, I tried to look up what it is and I'm still not sure. So we can, I think, but please maybe open an issue on GitHub because we need more information, I think. Thanks for suggestion though because, yeah, you are an AWS expert. The next question is again from Miras Lafatt-Kertz. Will there be enough build service available to Fedora users sometime? Well, we are definitely working on a was built or rather image builder as a service, but I cannot guarantee any availability at the moment. But we are working on image builder as a service. Okay. Thank you. The next question is from Richard. Is the newly built image based on the system running or C build? In other words, can a Fedora 33 system can only build another Fedora 33 images? Okay. If you are using Composer or Composer CLI, yes, then Fedora 33 can build only Fedora 33. But this is just the limitation of the API. Internally, we are able to build cross distro. We are able to build images like cross distro. So we actually were able to build rel images on Fedora and Fedora images on rel. But it's not just, it's not currently exposed to in the API. Thank you. Thank you. The next question is from Mark. Can it use cache to PMS so it doesn't take three hours to build? Well, it depends. So we definitely don't use the system cache. We download RPMs for ourselves. If you build several images that are similar and use the same RPM set, we cache the RPMs, but only those that were downloaded by OS build Composer itself. So we do not share any caches with the system. We are trying to be as... We are trying to separate OS build Composer from the system as much as possible. Thank you. I'm not sure, but probably already answered. What does blueprint mean? Okay, so blueprint is a definition of how I want the image to look. So I can put additional packages into blueprint. I can add some more customization like enabling services, adding users, what else. Yeah, customize the internal command line. And there are definitely some more. And I think that they are in the guides on the OS build.org website. If not, just bring us and we will send you documentation. Thank you, Andrei. And probably the last question from Mirasa. And it's in the house. I'm afraid we have to move to the chat room. What blueprints are planned to be added? The current list seems quite limited. And there is a link on that blueprint reference on the welder.io webpage. Yes, so we have our own blueprint reference. You can see it in the slide here. It's OS build.org slash guides and it contains a blueprint reference. And we know that the set of customizations is limited. For example, if you compare it to the available customizations in Ansible playbooks, but there are no current plans for adding new customizations like we don't have any exact plans right now. But if you want some specific customizations, feel free to open an issue in the OS build composer repository. Andrei, do we want to add something to this? Yeah, surely. Go to our GitHub and just say us what you want because we are building images and we have a limited understanding of what people need. So just tell us and we can chat and we can decide how to approach the problems that our users have because we are not really sure what users want. So please come to us and tell us what you want. We really want to hear it.