[00:00.000 --> 00:17.760]  We're starting now. Please. Please quiet down.
[00:17.760 --> 00:20.560]  Hello folks. Today we are here to talk about Fedora
[00:20.560 --> 00:24.720]  Corvus and how you can use that to do some fun stuff.
[00:24.720 --> 00:29.200]  The fun stuff being, you know, hosting your own dedicated multiplayer server so that you
[00:29.200 --> 00:34.160]  and your friends can have some fun. I'm joined here by Sumanthro, myself Akash
[00:34.160 --> 00:38.720]  Deep Dhar. We both work for Red Hat, but we are Fedora Project Contributors, and part
[00:38.720 --> 00:46.400]  of Fedora Council as well. So we welcome you to this talk.
[00:46.400 --> 00:50.600]  So about the things that we would want to talk about, the first and the foremost thing
[00:50.600 --> 00:55.680]  would of course be the OS, the thing that we run our containers on, and why exactly
[00:55.680 --> 01:00.440]  should you give a damn about it when there are like a plethora of Linux distributions
[01:00.440 --> 01:04.120]  out there with their own twists and turns attached to them.
[01:04.120 --> 01:09.840]  The next thing is of course putting that operating system to use, that of course is to have our
[01:09.840 --> 01:16.360]  own dedicated Minecraft server, understand how that process works and how easy or difficult
[01:16.360 --> 01:21.080]  it can be to actually put that to use. We'll put that to use again for the Valheim
[01:21.080 --> 01:26.120]  server too, because guess what? The community is great, and the folks have always created
[01:26.120 --> 01:31.000]  containers, and when it comes to containers, we always have something, some kind of platform
[01:31.000 --> 01:35.720]  to make use of. And by all means, if you trust me enough,
[01:35.720 --> 01:39.560]  you can totally scan this QR code, and it will lead you to the documentation, so you
[01:39.560 --> 01:43.960]  can totally go along with the talk, because this will be more hands-on. We'll be doing
[01:43.960 --> 01:49.400]  stuff over here, and we'll be making you folks understand as to what is happening behind
[01:49.400 --> 01:54.200]  the scenes and why exactly are we doing that. Or you can totally head over to the schedules
[01:54.200 --> 01:59.120]  page on the Container Step Room and find our links over there, so documentation is
[01:59.120 --> 02:05.120]  over there as well. Speaking of the operating system that we're
[02:05.120 --> 02:12.200]  going to talk about, what exactly is Fedora CoreOS? To begin with, it's a set of packages
[02:12.200 --> 02:17.840]  that's very minimal in nature, but it's very focused to the container-based workflows.
[02:17.840 --> 02:22.320]  So you won't get to see a lot of bells and whistles out of the box. Sure, there's an
[02:22.320 --> 02:28.200]  option to add those by yourself whenever you feel like, but then again, it's the networking,
[02:28.200 --> 02:33.200]  it's the container-based workflows like Moby, Podman, which I installed over there, as well
[02:33.200 --> 02:37.480]  as some tools like Firewall that you would need to make sure that people actually connect
[02:37.480 --> 02:42.040]  to your containers and be able to do what they want to do, which are pre-installed,
[02:42.040 --> 02:46.920]  which gives you just enough of a stuff to get started, and a canvas to actually add
[02:46.920 --> 02:52.520]  your own distributions, your own packages on the top of it, and grow upon it as you go
[02:52.520 --> 02:58.120]  on. And there's this thing called RPMOS Tree, which is based on LibOS Tree. The entire file
[02:58.120 --> 03:03.160]  system is transactional in nature, which essentially means that if I were to add packages on the
[03:03.160 --> 03:09.720]  top of the existing deployment, well, an existing set of installed packages, I can do so by
[03:09.720 --> 03:14.320]  ease without actually worrying that, oh, what's going to happen if I add this bleeding edge
[03:14.320 --> 03:20.520]  package? Will my deployment stop failing to work? And if it does, you can always find
[03:20.520 --> 03:25.440]  your way back. It's a Git kind of a workflow, so if you understand Git, it's pretty much
[03:25.440 --> 03:30.680]  like that, so you can always rebase your deployments, your own set collection of packages at any
[03:30.680 --> 03:37.400]  point in time, and just fall back at any point in time you want to go back to. The next thing
[03:37.400 --> 03:44.200]  is the fact that this is secure as well as scalable. So we, of course, would like to
[03:44.200 --> 03:49.800]  have this not only deployed in bare metal servers, but as well in a plethora of VMs
[03:49.800 --> 03:57.160]  having their own set of purposes. Now, the way we do that is by the use of configuration,
[03:57.160 --> 04:02.440]  and it's kind of difficult that you need to configure like tens of thousands of machines
[04:02.440 --> 04:08.760]  with hand, so guess what? You don't. You use something called beauty in configuration,
[04:08.760 --> 04:13.560]  which is a human readable form of something called ignition, and what it exactly does
[04:13.560 --> 04:19.560]  is you specify what kind of change that you want to make on that operating system. Some
[04:19.560 --> 04:24.560]  users that you want to add, some files that you want to make create, some networking rules,
[04:24.560 --> 04:30.400]  firewall rules, services to start stuff like that. You can do so so that when in the first
[04:30.400 --> 04:34.200]  boot, you get the operating system exactly the way you want, so you don't really have
[04:34.200 --> 04:38.360]  to install stuff and then configure it and then do that like thousands of times just
[04:38.360 --> 04:43.800]  because scalability is the thing. The next thing that I want to talk about is the fact
[04:43.800 --> 04:49.840]  that this operating system is available in not just x86 underscore 64, but in a lot of
[04:49.840 --> 04:58.080]  other places, architectures such as AR64 and ST90X as well, and we plan on providing the
[04:58.080 --> 05:07.080]  support for other operating systems architectures in the coming times. Speaking of the minimal
[05:07.080 --> 05:13.240]  set of packages, how minimal is it that we're talking? Let's give that a number. So we have
[05:13.240 --> 05:19.680]  like three release sets, the one for stable, the testing, as for us next, they are determined
[05:19.680 --> 05:28.600]  by the number at the penultimate decimal place, so 3.0 is stable, 2.x is testing, and 1.x
[05:28.600 --> 05:34.960]  is next. And you can totally see what those purposes are for and why exactly would someone
[05:34.960 --> 05:41.640]  want to go for a next over stable or vice versa. So say for instance, if there's a contributor
[05:41.640 --> 05:45.640]  who wants to develop this thing, they want to test all the bleeding edge packages that
[05:45.640 --> 05:51.000]  comes to this platform, they know what they can choose, and for the ones who really want
[05:51.000 --> 05:54.480]  to set up a server for their home people, they don't really want to move around a lot
[05:54.480 --> 05:59.600]  of stuff. They can either go for stable or they can reach out to our friends at CentOS
[05:59.600 --> 06:08.680]  because they have a CentOS team called OS2. So how exactly does this operating system
[06:08.680 --> 06:14.960]  become secure and scalable? I mean, I do sure like giving a business pitch because it's
[06:14.960 --> 06:22.320]  all buzzwords. So there are ways to make sure that the packages that you have installed
[06:22.320 --> 06:30.000]  or to say layered on the top of your existing installation, the way it gets automatically
[06:30.000 --> 06:35.000]  updated is very much in your control, which essentially means that it can go out in the
[06:35.000 --> 06:39.920]  open, start downloading everything, every new and bleeding edge stuff if you ask it
[06:39.920 --> 06:45.800]  to, or just hold back on it just because you want a stable operating system, you want to
[06:45.800 --> 06:53.320]  really curate the packages that you end up having so you have a lesser variness to updates
[06:53.320 --> 06:58.760]  that you end up having. So it's totally in your control and by all means there are ways
[06:58.760 --> 07:05.640]  to totally disable automated updates as and when you see fit. And these updates for the
[07:05.640 --> 07:11.840]  packages that you have installed, these don't get applied as soon as they get installed,
[07:11.840 --> 07:18.960]  but rather you kind of make those applications of those updates when you want them to happen.
[07:18.960 --> 07:24.480]  Usually it's a reboot because, well, the service actually happens to go through all the packages
[07:24.480 --> 07:29.840]  and refresh them based on the updates that has happened in the last boot, but you can
[07:29.840 --> 07:34.720]  always do it either live or in the next time as well. So at any point in time you feel like
[07:34.720 --> 07:39.120]  that a certain update has gone through which should not have, you can rest assured because
[07:39.120 --> 07:43.640]  that has not yet applied and you can always fall back to the previous deployment. And
[07:43.640 --> 07:47.400]  oh, I just happened to explain the last point. So that is rolling back whenever you feel
[07:47.400 --> 07:55.240]  like it. So depending on how you want to use this, you can use it on a Raspberry Pi if you
[07:55.240 --> 08:01.280]  are having one on your shelf gathering dust or you can have multiple VMs of yours on that
[08:01.280 --> 08:06.040]  desktop of yours that you think is an overkill and you don't use it anything else other than
[08:06.040 --> 08:12.120]  gaming. And of course there are choices to use it on the cloud too, which we totally suggest
[08:12.120 --> 08:17.120]  because this is something that we want to deploy on scale. So the kind of replicated
[08:17.120 --> 08:21.880]  deployment that you can have kind of depends on the kind of purpose that you would want
[08:21.880 --> 08:31.360]  to use this for. Right. So that's basically about operating system itself. Now we're going
[08:31.360 --> 08:36.960]  to make that thing, put that thing into use and understand how we can do some fun stuff,
[08:36.960 --> 08:43.800]  you know, set ourselves up an environment on this laptop itself. I set myself up a virtualization
[08:43.800 --> 08:50.800]  host and I'll configure it to the way I want it to. So if I want a user, I'll add it there.
[08:50.800 --> 08:55.840]  If I want a server to run in a certain way, maybe allow for no more than 32 people, I'd
[08:55.840 --> 09:01.320]  do so too. And by all means here again, this is a thing that you can follow along. So you
[09:01.320 --> 09:08.320]  can feel free to read the documentation by scanning the QR code and we'll move on to
[09:08.320 --> 09:15.240]  the next one. Right. So the set up environment that we have in place is VMware workstation.
[09:15.240 --> 09:19.480]  We really wanted to make sure that things are a lot more easier and off-limited scope
[09:19.480 --> 09:25.560]  for scope of this presentation. But you can use Quemu, you can use virtual box, you can
[09:25.560 --> 09:30.200]  use anything that you want or if you want to just nail it, you really want to make use
[09:30.200 --> 09:35.400]  of a bare metal too. And the specification that we provided it for are listed over here
[09:35.400 --> 09:41.520]  and for this case just because we want a server that actually runs, that actually is something
[09:41.520 --> 09:45.640]  that won't get a lot of packages, a lot of updates down the line, we really want to make
[09:45.640 --> 09:51.480]  sure that this runs in the long term, we have approached the stable stream for this one.
[09:51.480 --> 09:58.280]  Right. So I'm going to exit out of the screen for a bit and go more into detail about the
[09:58.280 --> 10:13.040]  stuff that I talked about over here. Right. So speaking of the demonstration, I have an
[10:13.040 --> 10:19.400]  entire directory of files that I need. Now these can either be firewall rules, the system,
[10:19.400 --> 10:24.880]  the units that I want to enable on the first boot, the packages that I want to install,
[10:24.880 --> 10:31.200]  the configuration for the swap that I want to put into place, stuff like that. So to
[10:31.200 --> 10:37.440]  get started, like I mentioned, we required a butane configuration. Now what exactly would
[10:37.440 --> 10:49.440]  that be? Let's find out. Pute cons and of course mine.pu. Well, basically it's just
[10:49.440 --> 10:54.480]  a list of directives that lets you do the stuff that you want to make happen. So if
[10:54.480 --> 11:01.400]  you want to create users with the set password for them, add SSS authorized keys, stuff like
[11:01.400 --> 11:06.880]  that, you can have them over here. The same goes for the stories, the symbolic links that
[11:06.880 --> 11:13.040]  you want to make happen from one folder to another directory. And you can have files
[11:13.040 --> 11:19.160]  that you source from a remote location and place it to somewhere else. Then finally we
[11:19.160 --> 11:24.720]  get to the system, the units part, where you can actually declare services. Now these services
[11:24.720 --> 11:31.720]  can either be for installing packages, adding firewall rules, enabling containers, stuff
[11:31.720 --> 11:37.520]  like that, and you can totally control them the way you want. And finally, you know, there's
[11:37.520 --> 11:43.480]  this cadence about what needs to be done first that you can use with the use of system D
[11:43.480 --> 11:51.440]  directives, like before, depends on, but you can also mention them over here. Right. So
[11:51.440 --> 11:55.880]  as you can see that we have roughly three system D units that we have mentioned over
[11:55.880 --> 12:01.720]  here. The first, of course, is to install portman compose and firewall D. We have portman
[12:01.720 --> 12:07.120]  pre-installed but not portman compose, so we might as well end up getting one. And the
[12:07.120 --> 12:12.720]  next is to allow Minecraft server to firewall. So before that we, of course, would reboot
[12:12.720 --> 12:18.640]  because like I mentioned, your updates only get applied when you want them to be applied,
[12:18.640 --> 12:24.840]  which by this case, by the default is reboot. There's also an option to apply them live,
[12:24.840 --> 12:30.400]  but then again you'd want to use them for applications like, well, a text editor or
[12:30.400 --> 12:33.840]  something of that kind, but definitely not for something that will end up becoming a
[12:33.840 --> 12:40.600]  service on itself. And then finally starting the dedicated server, now that the stuff that
[12:40.600 --> 12:50.240]  we needed for the firewall D service rules are everything in place. So just to avoid
[12:50.240 --> 12:56.480]  using more time during the presentation, what we did was, well, we did that in the hindsight
[12:56.480 --> 13:03.480]  like previously. And now what we have over here is the IP that we can connect to the
[13:03.480 --> 13:09.480]  container, the one that's running firewall D, the one that runs that firewall D service
[13:09.480 --> 13:17.560]  as well as the Minecraft dedicated server. To go forward in detail, I would show the
[13:17.560 --> 13:25.080]  status of the units that I mentioned off, like those for allowing these and depending
[13:25.080 --> 13:30.040]  on what kind of condition that you make happen, you can either make them run once, like if
[13:30.040 --> 13:34.160]  the firewall D service has been enabled, so you don't want to enable it again. So you
[13:34.160 --> 13:38.800]  can always put a flag of some kind telling that if a certain condition satisfies, which
[13:38.800 --> 13:46.560]  it seems to have, it won't run again. So the next thing that I want to show you is,
[13:46.560 --> 13:53.760]  of course, the server itself. So if I were to follow a certain unit, let's just say start
[13:53.760 --> 14:00.600]  Minecraft server, but I'm going to save myself some effort and go like that. So we have this
[14:00.600 --> 14:07.520]  container right here that's running on Podman. And yeah, there's this internal IP address
[14:07.520 --> 14:13.840]  as well that lets us connect to that. And finally, about the services that lets you
[14:13.840 --> 14:21.480]  install both Podman Compose as well as the firewall D. We'll head over here. Where's
[14:21.480 --> 14:46.280]  the terminal? There it is. And do, of course, mine. It's just a moment. And allowing system
[14:46.280 --> 14:51.680]  D system, allowing Minecraft server to the firewall. So we have set also the condition
[14:51.680 --> 14:58.240]  which tells that once that thing is done, you create a file called done, allow Minecraft
[14:58.240 --> 15:02.720]  server to firewall. So with the services like these, we kind of make sure that the service
[15:02.720 --> 15:09.360]  runs exactly when we want it to and not any time more than that. So once it's done, it's
[15:09.360 --> 15:14.520]  done. And of course, the condition for setting up in the first boot kind of falls in line
[15:14.520 --> 15:21.520]  for the one that helps us install these packages, especially for the Podman Compose and firewall
[15:21.520 --> 15:29.760]  D. So condition for the first boot is true, but you reboot after this thing has completely
[15:29.760 --> 15:36.480]  done. And by that, we help applying these packages on the existing deployment. Right.
[15:36.480 --> 15:44.120]  Let's say we'll go over here and we'll check the IP address again. This happens to be,
[15:44.120 --> 15:49.000]  this is not forwarded. So as much as any of you folks have Minecraft installed, I'm really
[15:49.000 --> 15:53.640]  sorry that you folks won't be able to connect to this one for the security purposes. But
[15:53.640 --> 15:59.240]  I'm going to connect to it and see what kind of world it gets me into. So we have the IP
[15:59.240 --> 16:08.080]  192.168.234.129. Let's see if it's reachable. Well, actually it's kind of a firewall D thing
[16:08.080 --> 16:19.080]  if it's the service runs. And if the rules have been applied, we would be able to. Hmm,
[16:19.080 --> 16:38.800]  just a moment folks. Oh, it seems to have run. Now to have a plan B and a plan C, I have
[16:38.800 --> 16:43.920]  heard stories of folks losing their presentations. They have like three flash drives. So I also
[16:43.920 --> 16:49.920]  thought of deploying one in my home, but we probably won't need that because guess what?
[16:49.920 --> 16:57.880]  We have a sour that says that it's running on this host and it's running on, well, the
[16:57.880 --> 17:02.200]  forced and set up that we have here. Well, the other one, the plan C, of course, does
[17:02.200 --> 17:06.840]  not happen to be a plan C anymore because there's something that I can't reach out to.
[17:06.840 --> 17:15.960]  So I'm going to connect over to this one. Right. So the worst thing that can happen
[17:15.960 --> 17:20.840]  to a player when the entire Minecraft world has happened. But then again, if I were to
[17:20.840 --> 17:29.560]  all tab out and were to check the logs of the service, I should be able to see that
[17:29.560 --> 17:36.800]  I indeed have connected and have reached. So, you know, folks can totally get creative with
[17:36.800 --> 17:42.200]  what they can do with this. They can have their own servers hosted on their local place,
[17:42.200 --> 17:47.000]  maybe have an OCI cloud to do some reverse proxing to have their friends connect to it
[17:47.000 --> 17:53.280]  as well. The possibilities are endless. And when it gets deployed on scale on cloud, it
[17:53.280 --> 17:58.760]  just goes to the next level. And it's not just for gaming, but rather for if you want
[17:58.760 --> 18:04.720]  to do a local deployment for Plex or anything for that matter, which uses containers, it
[18:04.720 --> 18:12.480]  is possible. Now I'm going to hand it over to Sumanthro to be able to talk about the
[18:12.480 --> 18:18.680]  Valheim setup, say, back to the presentation. Or to you, Sumanthro.
[18:18.680 --> 18:25.880]  Hey, guys. So exactly much like the Minecraft setup, we have the Valheim setup, which is
[18:25.880 --> 18:33.000]  basically setting up the environment variables, configuring the host, making it work. Technically
[18:33.000 --> 18:55.600]  all the documentation has been put out on that QR code. So, if I go over here. Yeah,
[18:55.600 --> 19:02.040]  so all the required files has been put out here. So, like Akash explained, we have a
[19:02.040 --> 19:08.280]  buton conf. So, if I go inside, you would have a buton conf configuration generated
[19:08.280 --> 19:13.800]  by this ignition file. So, if you look at it over here, the buton conf configuration
[19:13.800 --> 19:20.600]  has the storage, the directories, and all we need the files, any rules. And finally,
[19:20.600 --> 19:27.520]  the system D unit services that needs to run, specifically in much like the exact case of
[19:27.520 --> 19:38.320]  Minecraft. If I go back, this is actually the ignition file. This is the back door of
[19:38.320 --> 19:45.800]  how CoreOS would basically look at that configuration and parse it for its own purposes. So, this
[19:45.800 --> 19:53.240]  is perfectly mission readable, not supposed to be edited by hand. But, you know, if you
[19:53.240 --> 19:57.440]  guys wanted to change something, that's supposed to be on the buton side of things. Coming
[19:57.440 --> 20:05.640]  back to the configuration, there's a root. There's supposed to be ETC system D and then
[20:05.640 --> 20:13.400]  the ZRAM generator service. And this one is swap on ZRAM service. By default, we have
[20:13.400 --> 20:22.800]  put a ZRAM zero as the default setting. It requires a bunch of RAM and we literally have
[20:22.800 --> 20:28.560]  put one of those services over there just to ensure things are going fine. Going back
[20:28.560 --> 20:36.000]  to my systems, there are going to be a server through the firewall. That's exactly the same.
[20:36.000 --> 20:47.800]  If I open it, that's a very basic, that's a very basic thing. Going back, we have the
[20:47.800 --> 20:56.640]  start well dedicated service and this one is going to have the podman compose parts
[20:56.640 --> 21:04.160]  and that's an execute script with the up and down. Coming back to the point, so one
[21:04.160 --> 21:13.320]  more thing, we actually hosted it on private servers back in the home. The way that we
[21:13.320 --> 21:22.520]  kind of can get it up and running right now is reaching, where was the terminal? Go ahead.
[21:22.520 --> 21:30.120]  So for the interest of time. I should probably practice turning on microphones before speaking.
[21:30.120 --> 21:35.840]  For the interest of time, what we'll do is we'll just not show the Valheim demo. Unfortunately,
[21:35.840 --> 21:41.480]  apologies for that. But this is totally reachable on the VM that we have set up over here and
[21:41.480 --> 21:47.120]  the port that it goes on is reachable. But the point being that these things are very
[21:47.120 --> 21:52.840]  possible, fun stuff and kind of gives you a reason why you would want to try a new workflow
[21:52.840 --> 21:58.160]  where the entire file system, the entire packaging workflow is nothing but a get kind of a thing.
[21:58.160 --> 22:02.080]  So you can always roll back, roll front, depending on what you want to do. And the best thing
[22:02.080 --> 22:08.400]  that you can do is, well, try it out today if you have a VM to spare or a device to do
[22:08.400 --> 22:14.640]  say. Right. So that's about it for the presentation. We'd really love to have your questions and
[22:14.640 --> 22:15.640]  answer them too.
[22:15.640 --> 22:45.080]  We have a bunch of time for questions.
[22:45.080 --> 22:49.680]  So thank you very much for your presentation. I had a question about the relationship between
[22:49.680 --> 22:57.640]  Fedora Core, Fedora Core OS and persistent storage. My understanding is that when you're
[22:57.640 --> 23:01.000]  working in containers, you want everything to be ethereal and temporary and don't worry
[23:01.000 --> 23:07.160]  about that. But like you mentioned, if you have some sort of media server, how would
[23:07.160 --> 23:12.720]  you address that sort of like persistent sort of ButterFS data pool? Is that part of butane
[23:12.720 --> 23:22.480]  or how is that configured and managed? The way we have it is by setting up mounts. The
[23:22.480 --> 23:27.160]  way it works is anything that gets affected by the installation, removal, updating of
[23:27.160 --> 23:32.660]  the packages, these are the ones that are very transient in nature. So these can get
[23:32.660 --> 23:37.520]  affected. But if you have mounts that lead to some different place, they most likely
[23:37.520 --> 23:42.840]  won't be, the home directory would most likely stay untouched. So as long as it does not
[23:42.840 --> 23:47.440]  have anything to do with a certain package, if it's not a file that gets introduced when
[23:47.440 --> 23:52.760]  you install a package or something of that kind, it for most likely won't be touched
[23:52.760 --> 24:10.120]  and it would always stay the safe. Any more questions?
[24:10.120 --> 24:34.920]  Okay. What is the relationship between 4.0.x and 4.0.i.o.t? And does it make any sense?
[24:34.920 --> 24:47.080]  Has everyone got that? What's the difference between Fedora CoreOS and what?
[24:47.080 --> 24:56.080]  Fedora IoT. So for the record, Fedora IoT was an official
[24:56.080 --> 25:03.720]  edition for a long time, which means Fedora would push in updates regularly. CoreOS recently
[25:03.720 --> 25:09.280]  became an edition which is a release back, which now brings into question the release
[25:09.280 --> 25:17.320]  criteria for IoT and the boards that we support. They were very officially declared as supported.
[25:17.320 --> 25:23.280]  But in case of CoreOS, there's no such official support that was given before. It was never
[25:23.280 --> 25:26.960]  made an edition. So that's one thing that you're missing out on. Second thing that you're
[25:26.960 --> 25:34.200]  missing out on is IoT, on the other hand, is released every six months with the release.
[25:34.200 --> 25:40.680]  Fedora in CoreOS, in this case, would have a stream cycle, which means the next would
[25:40.680 --> 25:46.920]  be if today we get a next stream, in 15 days that would become testing, and then in next
[25:46.920 --> 25:53.040]  15 days it would become the stable. And then that's how it's going to roll. Obviously,
[25:53.040 --> 25:59.560]  given the fact that the next stream is tested by the CoreOS's own CI, which runs for almost
[25:59.560 --> 26:05.160]  all the basic tests which is required for the thing to run, both are based out of OS
[26:05.160 --> 26:11.560]  free. But again, every 15 days, CoreOS updates to the next stream or moves through the next
[26:11.560 --> 26:25.800]  stream. In case of IoT, you get it every six months.
[26:25.800 --> 26:33.120]  Hi, thanks for the talk. I would love to see this kind of bootstrapping of CoreOS happening
[26:33.120 --> 26:41.000]  on SystemDN spawn, for instance. Would that be feasible, like having that butane declarative
[26:41.000 --> 26:49.280]  way of just instantiate me something under SystemDN spawn? Is that something that can
[26:49.280 --> 26:56.440]  work already? It technically can. But then again, we kind of have to understand if SystemDN
[26:56.440 --> 27:02.800]  spawn, well, the environment inside of it will have SystemDN or not. So it's very much
[27:02.800 --> 27:10.080]  possible. And one of the use cases that I've seen using it is building packages or testing
[27:10.080 --> 27:16.760]  them for that matter. So the very fact that, you know, you don't really have to configure
[27:16.760 --> 27:21.640]  it when it's up, but rather decide how it's going to look like from the get-go, and that
[27:21.640 --> 27:29.640]  deployment can be replicated like anywhere. So that really makes it a prime image of some
[27:29.640 --> 27:34.480]  kind. And it does not even have to be a container image, right? That thing can be based upon
[27:34.480 --> 27:39.760]  and using a virtual machine or SystemDN spawn, as you mentioned, you can have that kind of
[27:39.760 --> 27:44.120]  a blueprint. But guess what? It's not a container. It's a full-blown operating system, which
[27:44.120 --> 27:48.640]  is running like it would on a bare-metal node.
[27:48.640 --> 27:49.640]  Okay.
[27:49.640 --> 27:50.640]  Thank you.
[27:50.640 --> 28:05.120]  Okay. This is the last question we can take.
[28:05.120 --> 28:12.000]  So I was wondering this ignition file is only applied on the first startup. Can we make
[28:12.000 --> 28:18.480]  some kind of declarative configuration for Silver Blue? Or for, and not for Silver Blue
[28:18.480 --> 28:23.480]  for CoreOS? Is this also supported?
[28:23.480 --> 28:27.800]  So if I get your question correctly, you are wondering if a certain configuration can be
[28:27.800 --> 28:44.440]  run again if I want to, on the same deployment.
[28:44.440 --> 28:49.280]  Right. So it's totally possible. You know, the thing that you end up getting after running
[28:49.280 --> 28:54.480]  these many steps after running the butane configuration is a deployment. So what you
[28:54.480 --> 28:59.520]  can do is you can use that deployment and run a butane configuration on the top of it.
[28:59.520 --> 29:04.160]  So that becomes your base deployment. And anything that you add on the top of it is
[29:04.160 --> 29:10.520]  the resulting deployment. So the very thing that deployment states in this case is a state
[29:10.520 --> 29:18.920]  in which the operating system is in right now. So, yeah. So if you just mangle the state
[29:18.920 --> 29:25.040]  to create a new one, that state becomes your existing state. That's about it.
[29:25.040 --> 29:32.680]  One last thing, guys. We have a Fedora boot. Feel free to go there, grab swags and whatnot.
[29:32.680 --> 29:55.760]  And thanks for attending. Thanks.
[29:55.760 --> 30:11.220]  Hey, guys.