WEBVTT 00:00.000 --> 00:12.000 Thank you, everyone. 00:12.000 --> 00:15.000 Thank you for being here today with us. 00:15.000 --> 00:16.000 My name is Perif Shivon. 00:16.000 --> 00:20.000 I usually go by Pingu and this is Eric Kertin. 00:20.000 --> 00:23.000 As an honest, we are going to talk to you a little bit about 00:23.000 --> 00:25.000 bootable containers and image mode. 00:25.000 --> 00:27.000 What are bootable containers? 00:27.000 --> 00:29.000 Well, we know what containers are. 00:29.000 --> 00:31.000 They have been around here for decades, 00:31.000 --> 00:33.000 and they have been the de facto standard today 00:33.000 --> 00:37.000 about how we want to deploy Linux use a space application. 00:37.000 --> 00:39.000 And they have been there for a long time, 00:39.000 --> 00:42.000 which means we have built, I need to speak louder. 00:42.000 --> 00:43.000 All right. 00:43.000 --> 00:44.000 I need my microphone. 00:44.000 --> 00:45.000 And in the microphone. 00:45.000 --> 00:47.000 That's going to be a challenge. 00:47.000 --> 00:49.000 That the microphone doesn't repeat in the room. 00:49.000 --> 00:50.000 It's just what I'm going to call it. 00:50.000 --> 00:53.000 So I'm going to try to speak to Spiny over there. 00:53.000 --> 00:56.000 If you can hear me, don't say anything. 00:56.000 --> 00:58.000 So containers have been there for a long time, 00:58.000 --> 01:00.000 which means we have built the only system around them. 01:00.000 --> 01:02.000 We have built tooling, we've been infrastructure, 01:02.000 --> 01:06.000 we've been platforms to build to leverage all of the capacity that it does. 01:06.000 --> 01:10.000 You know, we've known this as the container native or the cloud native 01:10.000 --> 01:12.000 to links and practices. 01:12.000 --> 01:15.000 The idea of bootable containers is to go one step further than that. 01:15.000 --> 01:18.000 And we don't want to include just the applications and its libraries, 01:18.000 --> 01:22.000 but what if we include the kernel with it and the bootholder and everything. 01:22.000 --> 01:25.000 So we basically no longer have an application image. 01:25.000 --> 01:27.000 We have an OS image. 01:27.000 --> 01:29.000 And that's why it was a call that image mode. 01:29.000 --> 01:33.000 And we can reuse all of the existing tooling and infrastructure 01:33.000 --> 01:39.000 to inspect but to build, to distribute, to deploy, to start, to inspect 01:39.000 --> 01:42.000 all of these containers because at the core of that technology, 01:42.000 --> 01:45.000 we remain in the OCI container standards. 01:45.000 --> 01:48.000 And the question becomes, say, why do we do that? 01:48.000 --> 01:53.000 Well, interesting to do that because suddenly we are managing our operating system 01:53.000 --> 01:56.000 in the same way that we are managing any of our applications. 01:56.000 --> 01:58.000 We allow to, we allow our system, 01:58.000 --> 02:03.000 our users in general, to have a single workflow to build anything. 02:03.000 --> 02:06.000 Be that an operating system, be that an application. 02:06.000 --> 02:10.000 As long as it's a container, it's going to be using the same approach. 02:10.000 --> 02:13.000 We can have, then, you know, all of the tooling that has been built around 02:13.000 --> 02:16.000 container security, being able to do audit container images, 02:16.000 --> 02:20.000 being able to check out for CVs, non CVs in the container images. 02:21.000 --> 02:23.000 Well, we can do that now at the OS cell. 02:23.000 --> 02:25.000 We can load that a little one-step further. 02:25.000 --> 02:28.000 We can look at it from the immutable OS perspective, 02:28.000 --> 02:31.000 you know, container images are immutable. 02:31.000 --> 02:33.000 You can write on them, but then you stop your container, 02:33.000 --> 02:36.000 you restart, and you start from a plane slate, 02:36.000 --> 02:38.000 which means you have increased security, 02:38.000 --> 02:40.000 which means you're maintenance using to be a lot easier, 02:40.000 --> 02:43.000 because that one container image that you're deploying 02:43.000 --> 02:45.000 is going to be the same container image, 02:45.000 --> 02:47.000 regardless of where you deploy it. 02:47.000 --> 02:49.000 So, that one operating system image, as you've built, 02:49.000 --> 02:52.000 is going to be the exact same one that you deploy everywhere. 02:52.000 --> 03:00.000 And we're using something called ComposeFS to increase the security of these images 03:00.000 --> 03:02.000 to ensure time are proofing. 03:02.000 --> 03:06.000 So, ComposeFS is a layer that's basically allows us to leverage 03:06.000 --> 03:10.000 FSVRT at the kernel level to ensure that the image that you're building 03:10.000 --> 03:13.000 is the same one that you've built, and it doesn't change 03:13.000 --> 03:15.000 since you've built it. 03:15.000 --> 03:18.000 And we can do that with all of the ecosystem that we've talked about before. 03:18.000 --> 03:22.000 We can do CICD, we can build things, we can audit them. 03:22.000 --> 03:25.000 So, to come back about immatibility, 03:25.000 --> 03:29.000 it's something that's scary, because well, I want to play with my image. 03:29.000 --> 03:30.000 I want to change it. 03:30.000 --> 03:34.000 While immatibility is not about preventing changes, 03:34.000 --> 03:36.000 it's about controlling that change. 03:36.000 --> 03:39.000 Being sure we secure from the get-go, we secure by design. 03:39.000 --> 03:42.000 It's about being intentional about a change. 03:42.000 --> 03:44.000 Not having a change happened by accident, 03:44.000 --> 03:49.000 or having a change that happens as consequences of something else. 03:49.000 --> 03:53.000 So, that's a quote from Matmoord, the city of Trangard. 03:53.000 --> 03:55.000 I basically give you the sense of it, 03:55.000 --> 03:57.000 I'm not going to read it entirely. 03:57.000 --> 03:59.000 But so, bootable container. 03:59.000 --> 04:00.000 We've mentioned it. 04:00.000 --> 04:03.000 We know what container images are. 04:03.000 --> 04:06.000 You have a basic image, and then you leave your libraries 04:06.000 --> 04:07.000 and application on top of this. 04:07.000 --> 04:10.000 Well, bootable image is the exact same thing. 04:10.000 --> 04:12.000 The average is the same technology. 04:12.000 --> 04:14.000 Still honestly, I compliant container, 04:14.000 --> 04:16.000 except it includes a kernel with it. 04:16.000 --> 04:18.000 It includes bootloader with it. 04:18.000 --> 04:21.000 But all of the tooling are on all of the infrastructure on success, 04:21.000 --> 04:24.000 which means we can build these workflows. 04:24.000 --> 04:25.000 And this is nothing new. 04:25.000 --> 04:27.000 You've seen this for a decade now. 04:27.000 --> 04:29.000 You have a container file. 04:29.000 --> 04:30.000 You build it. 04:30.000 --> 04:31.000 You push it to registry. 04:31.000 --> 04:32.000 Nothing new here. 04:32.000 --> 04:33.000 Damn. 04:33.000 --> 04:35.000 What are we here for? 04:35.000 --> 04:37.000 Well, the beauty here is that now, 04:37.000 --> 04:39.000 with a bootable image containers, 04:39.000 --> 04:42.000 you've heard that container image into an actual disk image. 04:42.000 --> 04:44.000 You can run that disk image into a mesh device. 04:44.000 --> 04:47.000 You can run it onto a cloud public private cloud. 04:47.000 --> 04:49.000 You can run it on a VM on your laptop. 04:49.000 --> 04:52.000 You can run it on your laptop itself. 04:52.000 --> 04:56.000 But the magic happens when you want to update it, 04:56.000 --> 04:58.000 because then you use the same workflow. 04:58.000 --> 05:00.000 You're still after your container image. 05:00.000 --> 05:03.000 You're going to be built to get a new updates. 05:03.000 --> 05:06.000 And then you're going to push that update to a container registry, 05:06.000 --> 05:08.000 just like you would do for a new application. 05:08.000 --> 05:12.000 And then your entire OS here is going to be updated via that container image. 05:12.000 --> 05:15.000 So it's nothing new except it's one step further. 05:15.000 --> 05:19.000 It's we're taking the idea of containerized and using this, 05:19.000 --> 05:23.000 this deployment mechanism, this approach to the next level, 05:23.000 --> 05:25.000 to include the entire operating system. 05:25.000 --> 05:28.000 Imagine not just the application image. 05:28.000 --> 05:30.000 And all of these happens through the magic of bootsy, 05:30.000 --> 05:33.000 which I'm going to let Eric talk to you about. 05:33.000 --> 05:35.000 Thank you. 05:36.000 --> 05:38.000 You know what? 05:38.000 --> 05:39.000 I'm going to hold. 05:39.000 --> 05:40.000 No. 05:40.000 --> 05:43.000 So again, we need to put the video there. 05:43.000 --> 05:45.000 Yeah, I've got it. 05:45.000 --> 06:02.000 Okay, so what is bootsy, bootsy is the tool that basically manages all this. 06:02.000 --> 06:04.000 It's the core tool. 06:05.000 --> 06:08.000 It's in the GitHub containers namespace. 06:08.000 --> 06:14.000 It builds upon over a decade of existing technologies from projects, 06:14.000 --> 06:17.000 such as OS tree and RPMOS tree. 06:17.000 --> 06:22.000 But it abstracts you away from a lot of the complexity. 06:22.000 --> 06:30.000 Because, yeah, most users and citizens of bootsy don't have to worry about the lower level details. 06:30.000 --> 06:32.000 So it abstracts upon all that. 06:32.000 --> 06:37.000 And as all these container like features appear just described. 06:37.000 --> 06:40.000 So yeah, it allows you to deploy bootsy systems. 06:40.000 --> 06:45.000 You can update systems with it. 06:45.000 --> 06:47.000 I should say there's actually a family of bootsy tools. 06:47.000 --> 06:49.000 So bootsy is the main one. 06:49.000 --> 06:52.000 But there's also like sister tools. 06:52.000 --> 06:54.000 You can do rollbacks. 06:54.000 --> 06:56.000 You can even do automated rollbacks. 06:56.000 --> 07:02.000 So let's say your system fails to boot five times. 07:02.000 --> 07:06.000 We have a tool that will that will check the boot counter and say, 07:06.000 --> 07:08.000 Okay, you failed five times. 07:08.000 --> 07:12.000 Let's reboot and rollback into the last version of the operating system, 07:12.000 --> 07:17.000 which was a non-good version and with healthy at least in the past. 07:17.000 --> 07:23.000 There's a stable API and an integrates with podman and all those family of 07:23.000 --> 07:27.000 container tools. 07:27.000 --> 07:29.000 So how does it work? 07:29.000 --> 07:31.000 What is a mutable? 07:31.000 --> 07:33.000 So what is an immutable OS? 07:33.000 --> 07:37.000 Obviously, we have to be reasonable at some point. 07:37.000 --> 07:41.000 So the whole idea is, yeah, it's reasonable at build times. 07:41.000 --> 07:44.000 So there's a base container. 07:44.000 --> 07:50.000 There's a base bootable container image that you can inherit from. 07:50.000 --> 07:54.000 And you can do your DNF installs, copy stuff. 07:54.000 --> 07:56.000 You can run whatever you want to. 07:56.000 --> 07:58.000 Really. 07:58.000 --> 08:00.000 And how does this work? 08:00.000 --> 08:07.000 So there's kind of three different types of file systems in an inability image. 08:07.000 --> 08:11.000 So there's an environment. 08:11.000 --> 08:16.000 This is a persistent but mutable file system because, 08:17.000 --> 08:19.000 yeah, not every device is unique. 08:19.000 --> 08:22.000 So you need something to manage the local state. 08:22.000 --> 08:26.000 So that would start the same on almost every device and 08:26.000 --> 08:29.000 and then manage the local state of that device. 08:29.000 --> 08:35.000 In ETC, what we do is, I don't create it will change, 08:35.000 --> 08:39.000 but it'll also take into account that the local configuration changes you've made. 08:39.000 --> 08:45.000 So to do it three way merge with the update from the container image. 08:45.000 --> 08:50.000 And basically all the other persistent files in the system are read-only 08:50.000 --> 08:53.000 and backed by FF's version to check that there. 08:53.000 --> 08:58.000 And they're intentional changes, like here you've explained. 08:58.000 --> 09:03.000 ETC is actually an interesting one because there's some versions of these boots, 09:03.000 --> 09:06.000 the operating systems where we make that completely read-only. 09:06.000 --> 09:11.000 So that's kind of configurable if you don't want the user to be able to make. 09:11.000 --> 09:15.000 Any local configuration changes, whatever. 09:15.000 --> 09:19.000 Although it's mutable at runtime because there are certain files that 09:19.000 --> 09:24.000 change at runtime, like I think ETC results. 09:24.000 --> 09:29.000 There are a small handful that needs to be mutable at runtime. 09:29.000 --> 09:34.000 So here are some base images we have for bootsy. 09:34.000 --> 09:38.000 We have for door-based ones and for stream-based ones. 09:38.000 --> 09:40.000 Where it had enterprise Linux based ones. 09:40.000 --> 09:44.000 And actually this is just a small subset because there's a universal blue family 09:44.000 --> 09:46.000 of operating systems from the community. 09:46.000 --> 09:51.000 But yeah, a lot of this is repetition, but yeah, you have your base images 09:51.000 --> 09:57.000 in container file, easy integration, CICD ship, that's all CIMages. 09:57.000 --> 10:02.000 Yeah, as I said, this is a suite of tools, this bootsy tools. 10:02.000 --> 10:04.000 This is not a bootsy tool. 10:04.000 --> 10:07.000 This is the one you use basically to build a base image. 10:07.000 --> 10:11.000 You can also use it to convert into the various formats, 10:11.000 --> 10:15.000 like the three virtualization formats specified here, 10:15.000 --> 10:23.000 and a condenser or a raw file that you just write directly to your disk. 10:23.000 --> 10:27.000 Okay, so yeah, this is a simple flow how it all works. 10:27.000 --> 10:32.000 Your system creates the container file, which is bootable image. 10:32.000 --> 10:35.000 He wants to deploy somewhere. 10:35.000 --> 10:38.000 He pushes it to his OCI container registry, 10:38.000 --> 10:42.000 whatever registry he may have in his infrastructure. 10:42.000 --> 10:46.000 And yeah, then that image gets pulled to the various devices 10:46.000 --> 10:50.000 that are looking for system updates, and it's cool. 10:50.000 --> 10:52.000 Thanks. 10:52.000 --> 10:55.000 Yeah, and we've not paid service, and we also have a raw back service. 10:55.000 --> 10:58.000 Say if a certain health check failed in a real life G, that's a bad version. 10:58.000 --> 11:00.000 I better roll it back. 11:00.000 --> 11:04.000 So yeah, that's related to the raw back to health checks. 11:04.000 --> 11:08.000 Yeah, so it's operating systems are obviously growing 11:08.000 --> 11:12.000 in complexity all the time, and more important than ever 11:12.000 --> 11:16.000 is to manage your dependencies in your container. 11:16.000 --> 11:20.000 So I don't know if you've used to, people in the room have used to 11:20.000 --> 11:24.000 as a renovator, dependable, but they're basically these bots that 11:24.000 --> 11:26.000 will automatically check for updates. 11:26.000 --> 11:30.000 And then open a PR in your GitHub or GitHub repo. 11:30.000 --> 11:34.000 And that's actually quite useful, because then the PR is open by the bot. 11:34.000 --> 11:38.000 And then you can go through your CI and run all your tests. 11:38.000 --> 11:44.000 And why this is useful with bootsy is, say, the bot has made the 11:44.000 --> 11:46.000 change to container file, then your CI CD. 11:46.000 --> 11:49.000 You can stack that container file as a container file, 11:49.000 --> 11:52.000 as a container file. 11:52.000 --> 11:56.000 Just with podment, run your tests as you want. 11:56.000 --> 12:00.000 Or if you want to more complete operating systems tests in your 12:00.000 --> 12:04.000 inner CI infrastructure, you can boot up full VM and run your test 12:04.000 --> 12:06.000 weeks. 12:06.000 --> 12:10.000 And the Mac, your PR is green or red, and someone can review it and merge, 12:10.000 --> 12:12.000 or whatever. 12:12.000 --> 12:16.000 So this is one of the most powerful things about bootsy. 12:16.000 --> 12:20.000 I'm about to open a program, use tag, yeah. 12:20.000 --> 12:24.000 Yeah, I think I explained all that. 12:24.000 --> 12:30.000 Container registries. 12:30.000 --> 12:36.000 So this is basically saying when you, once you merge your PR, 12:36.000 --> 12:40.000 if your automation is, if you set up your automation, 12:40.000 --> 12:44.000 you can just push directly to the registry, then all the various nodes 12:44.000 --> 12:48.000 can pull it. 12:48.000 --> 12:52.000 Yeah, it's, if you're familiar with podman scope, 12:52.000 --> 12:54.000 it's all the same tooling, as PR said, 12:54.000 --> 12:58.000 that we've had for like a decade, and also it's all very mature 12:58.000 --> 13:00.000 technologies. 13:00.000 --> 13:02.000 Yeah, you can use a red hack, 13:02.000 --> 13:06.000 quay as an OCI registry, or maybe even in house OCI registry, 13:06.000 --> 13:08.000 which is perfectly fine to use also. 13:08.000 --> 13:16.000 Yeah, so this is just a scribe not, obviously when it's stored in the OCI, 13:16.000 --> 13:20.000 container registry, when you pull it down, 13:20.000 --> 13:22.000 it's actually not a bootable container. 13:22.000 --> 13:24.000 At that point, it's just a normal podman container, 13:24.000 --> 13:26.000 which is actually kind of cool, because you can do your podman 13:26.000 --> 13:28.000 and run and play around with it. 13:28.000 --> 13:32.000 But obviously there's a conversion step that will 13:32.000 --> 13:36.000 convert it to an actual undisk format for 13:36.000 --> 13:40.000 public cloud loadage devices, bare metal servers, that kind of thing. 13:40.000 --> 13:48.000 Yeah, so quadlicious is a tool that's been 13:48.000 --> 13:50.000 around for a couple of years now. 13:50.000 --> 13:54.000 It's basically if you want to start a container as a 13:54.000 --> 13:58.000 system de-service, that's the long in the short of it. 13:58.000 --> 14:02.000 And the cool thing about footsie images, actually, you can 14:02.000 --> 14:06.000 you can boost full operating systems with them, but with this slide, 14:06.000 --> 14:09.000 it's actually showing, you can also run them as containers. 14:09.000 --> 14:13.000 So actually, to say, I'm copy of an operating system 14:13.000 --> 14:21.000 can be the OS, end an application container, also, which is quite useful. 14:21.000 --> 14:29.000 You know, they're very mutable, then you can use the same version of an operating system for multiple cases. 14:29.000 --> 14:33.000 That's your creep on, do you? 14:33.000 --> 14:37.000 I'm going to skip this slide because I'm running out of time. 14:37.000 --> 14:41.000 Yeah, so join the community, get involved, try it out, give us feedback, 14:41.000 --> 14:45.000 open PRs, any questions? 14:51.000 --> 14:53.000 I apologize if I went through something faster than just 14:53.000 --> 14:55.000 very time, but yeah. 14:55.000 --> 14:57.000 No, you're better than that. 15:03.000 --> 15:07.000 Two questions, one is, what's the part on how do you store it on this? 15:07.000 --> 15:11.000 Is that, like, they can't be fine, or is there always the same type of platform 15:11.000 --> 15:17.000 that you eventually have the container unpacked off on this, give it to me? 15:17.000 --> 15:19.000 Um, there's a bit of a question for them. 15:21.000 --> 15:23.000 The question was, 15:23.000 --> 15:25.000 yeah, it's tricky. 15:25.000 --> 15:27.000 It was basically what is the file format on this? 15:31.000 --> 15:35.000 Yeah, it's, it's, we flew by it in the slides, 15:35.000 --> 15:39.000 but it's basically powered by something called composer-face, 15:39.000 --> 15:43.000 which is an arrow-a-face file system. 15:43.000 --> 15:45.000 It's kind of like a content-to-dressed door. 15:45.000 --> 15:49.000 It's a mercury-ish peer-eves stated. 15:49.000 --> 15:53.000 And let's say I come, and let's see, I come, 15:53.000 --> 15:55.000 image is a mercury-based. 15:55.000 --> 15:59.000 So you have, if you have two container image that are using the 15:59.000 --> 16:03.000 sem file, they're going to address that file using the shell, the file, and so on. 16:03.000 --> 16:05.000 So it's a mercury-tree, it's just like your Gitribo, 16:05.000 --> 16:09.000 and that means if you have two files in the same image that 16:09.000 --> 16:11.000 be only present once in a disk. 16:11.000 --> 16:13.000 And the underlying technology for image mode is up here in 16:13.000 --> 16:15.000 with three, which also happens to be based on mercury. 16:15.000 --> 16:17.000 So the idea is that we are leveraging the file that the, 16:17.000 --> 16:21.000 you see, I, containers image is based on mercury, 16:21.000 --> 16:25.000 to be able to deploy in our PMOE-3, mercury-based, 16:25.000 --> 16:29.000 which is then mounted as a regular operating system when you put. 16:29.000 --> 16:31.000 I would say on the last question, Alexander Larsson has 16:31.000 --> 16:33.000 done talks on composer-face. 16:33.000 --> 16:35.000 You should, what? 16:35.000 --> 16:37.000 That's good. That's good. Yeah. 16:37.000 --> 16:39.000 That's good. 16:39.000 --> 16:43.000 I will say on the last question, Alexander Larsson 16:43.000 --> 16:45.000 has done talks on composer-face. 16:45.000 --> 16:49.000 You should watch that because it's hard to answer that well 16:49.000 --> 16:51.000 in 10, 20 seconds. 16:51.000 --> 16:55.000 Okay. 16:55.000 --> 16:57.000 Well, cool. 16:57.000 --> 17:01.000 The question was how do we handle entry points? 17:01.000 --> 17:07.000 In the context of a bootable container image, 17:07.000 --> 17:11.000 entry points are really make as much sense because when you boot 17:11.000 --> 17:15.000 a real operating system, you're stashing from systemD 17:15.000 --> 17:17.000 and all its various services. 17:17.000 --> 17:21.000 It's not just one service you're stashing. 17:21.000 --> 17:23.000 You could add an entry point 17:23.000 --> 17:25.000 and when you start a bootable image as a container, 17:25.000 --> 17:27.000 it would work. 17:27.000 --> 17:31.000 In the context of a full operating system, 17:31.000 --> 17:35.000 I don't think there's much value in entry points because, 17:35.000 --> 17:37.000 you start with kernel and systemD and systemD 17:37.000 --> 17:39.000 that, like, a thousand things, so it's... 17:39.000 --> 17:41.000 What do you expect to ignore any points 17:41.000 --> 17:44.000 or any of the things that only starts as a bootable way? 17:44.000 --> 17:45.000 Yeah. 17:45.000 --> 17:47.000 Unless you start a via podman run, 17:47.000 --> 17:49.000 then it just starts as an normal container, 17:49.000 --> 17:51.000 so it will take the entry point into account. 17:51.000 --> 17:53.000 Yeah. 17:55.000 --> 17:56.000 Okay. 17:56.000 --> 18:00.000 Is your vision of a slash EDC, 18:00.000 --> 18:02.000 slash verse, slash run? 18:02.000 --> 18:04.000 The same as systemDs1, 18:05.000 --> 18:08.000 because they're two are trying to spend a dice 18:08.000 --> 18:14.000 the way exactly as EDC or run are used. 18:16.000 --> 18:18.000 There are differences, yeah. 18:18.000 --> 18:20.000 The short answer is there. 18:20.000 --> 18:22.000 Oh, sorry. 18:22.000 --> 18:23.000 Sorry. 18:23.000 --> 18:24.000 The question was, 18:26.000 --> 18:29.000 is are the way we treat ATC via 18:29.000 --> 18:32.000 and user the same as the way 18:33.000 --> 18:39.000 systemD defines it for their mutability approaches? 18:39.000 --> 18:42.000 There are some similarities, some differences. 18:42.000 --> 18:43.000 That's it. 18:43.000 --> 18:44.000 Yeah. 18:44.000 --> 18:45.000 They're not the same. 18:49.000 --> 18:51.000 Who wants to go to you? 18:51.000 --> 18:52.000 I have to go to you. 18:52.000 --> 18:53.000 I have to go to you. 18:53.000 --> 18:54.000 I have to go. 18:54.000 --> 18:55.000 Okay. 18:55.000 --> 18:58.000 And I saw that you had the basic image 18:58.000 --> 19:00.000 from federal action. 19:00.000 --> 19:03.000 Is that the way the cabinet is coming from? 19:03.000 --> 19:06.000 Or is it considered the size for the cabinet systemD 19:06.000 --> 19:09.000 and all the other stuff they need to run? 19:09.000 --> 19:12.000 I would say it's not in the document, right? 19:12.000 --> 19:13.000 The kernel is already. 19:13.000 --> 19:15.000 Also, the question was, 19:15.000 --> 19:18.000 where is the kernel in the bootable container? 19:18.000 --> 19:20.000 Does it come from bass image? 19:20.000 --> 19:22.000 You inherit from the from line? 19:22.000 --> 19:25.000 Or is it someplace else? 19:25.000 --> 19:26.000 Where is it? 19:27.000 --> 19:30.000 And the answer is, the kernel is already pre-baked into the bass image. 19:30.000 --> 19:33.000 Actually, an upcoming feature, I'm aware of, 19:33.000 --> 19:34.000 because I'm excited about it. 19:34.000 --> 19:38.000 It doesn't exist, you can actually switch out the kernel 19:38.000 --> 19:42.000 from your bass operating system if you want. 19:42.000 --> 19:45.000 That doesn't exist yet, so I shouldn't talk about it, 19:45.000 --> 19:46.000 but I know it's coming. 19:46.000 --> 19:47.000 Yeah. 19:47.000 --> 19:50.000 Here's his hand up a little under. 19:57.000 --> 20:12.000 So the question is, 20:12.000 --> 20:17.000 we spoke about slash user being read only, 20:17.000 --> 20:20.000 slash fire managing local state, 20:20.000 --> 20:24.000 and slash ETC kind of managing configurations. 20:24.000 --> 20:28.000 And the question was, what happens to var and ETC 20:28.000 --> 20:31.000 when you roll back? 20:31.000 --> 20:34.000 When you roll back, 20:34.000 --> 20:36.000 there's no changes happen in var actually, 20:36.000 --> 20:38.000 as far as I'm aware. 20:38.000 --> 20:43.000 ETC, I don't think there are any changes there either, 20:43.000 --> 20:49.000 but actually, if there is an option to make ETC read only, 20:50.000 --> 20:56.000 and if you're worried about the roll back going perfectly, 20:56.000 --> 21:00.000 I would highly recommend turning that option on to make ETC read only, 21:00.000 --> 21:04.000 because then ETC rolls back just like user would, 21:04.000 --> 21:06.000 like bite for bite. 21:19.000 --> 21:27.000 We still have the previous one. 21:27.000 --> 21:29.000 We still have the previous image. 21:29.000 --> 21:30.000 So in case of a roll back, 21:30.000 --> 21:34.000 we can still mount ETC from the previous one, from the previous state. 21:34.000 --> 21:36.000 But the question about var is, 21:36.000 --> 21:38.000 so it's going to be the exact same challenge 21:38.000 --> 21:41.000 that you would have today on a containerized application, 21:41.000 --> 21:44.000 that on the point of grade changes to database schema. 21:44.000 --> 21:46.000 You're going to have the same challenge and you're going to, 21:46.000 --> 21:49.000 if you want to be able to do a roll back, 21:49.000 --> 21:51.000 you will need to have as part of your roll back. 21:51.000 --> 21:54.000 Many can use them a way to don grade database schema, 21:54.000 --> 21:58.000 just like you would have today on an application that just updated, 21:58.000 --> 22:00.000 the database can be opened update. 22:00.000 --> 22:03.000 So some challenges, different scale, but some challenge. 22:03.000 --> 22:05.000 Just a question. 22:11.000 --> 22:13.000 Could you repeat that? 22:13.000 --> 22:25.000 I don't know, because it's first I've heard of it. 22:25.000 --> 22:31.000 The question was, what's the difference between this and Linux case? 22:31.000 --> 22:33.000 Just being honest, I don't know. 22:33.000 --> 22:36.000 That's the first I heard of Linux case. 22:36.000 --> 22:38.000 Unless, yeah. 22:38.000 --> 22:40.000 Sorry. 22:40.000 --> 22:44.000 All the questions. 22:44.000 --> 22:49.000 So what is it, as we did you talk to the content mate? 22:49.000 --> 22:52.000 And we have an automatic tool to convert a classic, 22:52.000 --> 22:57.000 or does a mesh to put C in a case of elements? 22:57.000 --> 22:59.000 The question is, 22:59.000 --> 23:02.000 the question is, what does it take to move a container image 23:02.000 --> 23:05.000 from an application to a boot C-based container image? 23:05.000 --> 23:11.000 And I would say, it's one line, the from. 23:11.000 --> 23:13.000 Yeah. 23:13.000 --> 23:17.000 So the question is more, like, I want to, you would say that the support 23:17.000 --> 23:19.000 to say the word where that's not what it is about. 23:19.000 --> 23:21.000 You repeat a little bit for the dynamic image, 23:21.000 --> 23:24.000 based on the dynamic image of this distribution. 23:24.000 --> 23:26.000 I want to use my own distribution. 23:26.000 --> 23:27.000 What's the use? 23:27.000 --> 23:28.000 Yeah. 23:30.000 --> 23:34.000 So the question is, yeah. 23:35.000 --> 23:37.000 I'm going to shorten the question because it was long. 23:37.000 --> 23:42.000 But the question was, these are basically pre-backed images 23:42.000 --> 23:45.000 that just work with Bootsie. 23:45.000 --> 23:48.000 What if you like have a classical container image, 23:48.000 --> 23:52.000 and you want to, you want to turn it into a Bootsie 23:52.000 --> 23:55.000 capable container image? 23:55.000 --> 23:59.000 You're basically looking for this tool, Bootsie image builder. 23:59.000 --> 24:03.000 So I would recommend you integrate your distribution 24:03.000 --> 24:08.000 with this tool, and this is basically, yeah, put your, 24:08.000 --> 24:13.000 you'll end up with a container image in a Bootsie format. 24:13.000 --> 24:16.000 And then you can treat it as a normal container, 24:16.000 --> 24:18.000 or a Bootsieable container. 24:18.000 --> 24:20.000 So that's the magic tool you need to integrate 24:20.000 --> 24:24.000 what if you want to create something from scratch. 24:24.000 --> 24:25.000 Yeah. 24:26.000 --> 24:46.000 So the question was, I believe it's possible to put the container 24:46.000 --> 24:54.000 in the container, and if so, how does this interact with the host 24:55.000 --> 24:56.000 kernel? 24:56.000 --> 25:00.000 And the answer is, it's very simple. 25:00.000 --> 25:03.000 If you're doing something like this, 25:03.000 --> 25:07.000 where you want to run two kernels, 25:07.000 --> 25:11.000 you start the Bootsie image as a VM, 25:11.000 --> 25:15.000 just in every day, Qem, UVM, or whatever, 25:15.000 --> 25:18.000 hypervisor you want to use. 25:18.000 --> 25:21.000 It's not something so bespoke, you just start as VM, 25:21.000 --> 25:24.000 if that's, if you want two kernels running. 25:24.000 --> 25:26.000 No, it's not that I want two kernels running. 25:26.000 --> 25:27.000 Yeah. 25:27.000 --> 25:29.000 And understand that you can start the kernel, 25:29.000 --> 25:32.000 and inside the container. 25:32.000 --> 25:36.000 Yeah, so if you're, if you're just testing the container, 25:36.000 --> 25:39.000 and you do Bootsie run container image, 25:39.000 --> 25:41.000 there's only one kernel. 25:41.000 --> 25:44.000 It's just a normal container when you use it in that fashion. 25:44.000 --> 25:47.000 Okay, so it does not boot the kernel in the container. 25:47.000 --> 25:48.000 No. 25:48.000 --> 25:51.000 But the kernel exists as files, but you don't touch it. 25:51.000 --> 25:55.000 It's only when you convert it to a VM format, 25:55.000 --> 25:58.000 or anaconda, or raw, that's when you boot it like 25:58.000 --> 26:01.000 a normal everyday system that you actually use the kernel 26:01.000 --> 26:03.000 from the bootable container. 26:03.000 --> 26:04.000 It's very flexible. 26:04.000 --> 26:05.000 All right. 26:05.000 --> 26:06.000 That's all that I'm here. 26:06.000 --> 26:08.000 So let's take a look at that. 26:08.000 --> 26:09.000 Thank you.