 Well, hello and welcome to another Dev Nation. I'm super excited to talk to you guys today because we have some really cool things to show you. We're going to be talking about containers. If you are familiar with the concept of the Linux container, or even if you're not familiar with the concept of the Linux container, we have a lot of great things to talk to you about. We're going to be diving in things like UBI and Podman, and we have an expert here at Red Hat on this specific topic. Scott McCarty has been working on this for years. He's known as FatherLinux on Twitter. So definitely check him out on Twitter. I'll actually provide the link later. And if you have questions, throw them into our chat. Feel free to just jump questions to the chat. We'll queue them up. I'll try to answer ones in real time, but at the same time, we'll save some for Scott later in the session. We're going to be moving fast today. It's only a 30-minute session, so just be prepared for that. And remember, if you can't hear, which you can't hear or you can't see, refresh the browser. That's always the secret sauce when it comes to working with us in these presentations. All right, let me turn it over to Scott. He's going to be live demoing all this great stuff. Ready, Scott? I am. Thanks for having me, Burr. So I'm going to share my screen. Do you guys see my screen OK? So I'm going to, this will be about 85% demo, but I do have just a few slides to kind of keep us on track and keep us where we want to be in the use case. So I'm going to do this use case-based. And I'm going to really highlight Podman a lot, which is a nice little developer tool that you can use to basically find, run, build, share, and deploy containers. And I kind of stick to that model to find, run, build, share, and then deploy is kind of what I'm going to walk through today. So I've been doing this for about six years. And six years ago, when I first started with Docker, was the first container engine that I had used that I really kind of changed the way I thought about doing operations work and development work. And the first thing we did was do a Docker find. And we would go out and find all these container images. And we were like, OK, cool, all these container images exist out there. What do we do with them? How do we determine if they're good? Sometimes we'd get a gut feeling about it. We'd run some of them. And then at some point, we'd say to ourselves, I want to do more than just run some base image that I find out there or some application that somebody else wrote. I want to add to it. And the way we do that is we build upon those images because they're built in layers. And we would go through this fine run build cycle a lot. And then at some point, we'd build something valuable and we'd say to ourselves, OK, I want to share. I need to share this work that I've done with somebody else because what's the point in doing work or creating value and adding that value to a body of work if you're not going to share it? And then at some point, you'd say to yourself, oh, OK, that's great. I've shared it. Some other people have contributed some work to that body I have. And now we want to deploy this thing in production. And so that was the journey that I've seen people taking. I'm going today to walk through this entire journey with some demoing of Podman, Quay, and OpenShift. So let me just jump over to the terminal because I think it'll be best to just walk through. So I have scripted this out so that hopefully this demo, the demo gods, will be kind to us. I have scripted out and we're going to basically walk through the fine run build, share, deploy process. So the first thing that we do when we start to think about standards are like, all right, let me go find a base image that I can use. I want to build off something. I need some place to start. And so in this case, I'm showing, I'm going to show you a command where we got, and we kind of searched the Red Hat Container Catalog. The command that I ran there was a Podman search, registry, blah, blah, blah. You see the long URL. And then what comes back is a whole bunch of container images that we have out on the Red Hat Container Catalog. And you'll see, OK, you would say to yourself, maybe I trust these container images. I trust Red Hat. They usually do pretty decent work. But I'm not 100% sure I trust them. So what I want to do is I want to show you there's actually another way to verify this, right? Not only can you just search on the command line, but a lot of times you're like, I need a little more information. I need to go out and kind of verify that these container images are what I'd really want. So in that scenario, you'd go out to the Red Hat Container Catalog here. And we provide a really nice command line, or a web-based interface to this. So let me put this in Red Hat Universal Base Image. And then what comes up is a list of container images that we have out here. And in particular, I was looking at the UBI-8 Red Hat Universal Base Image 8. We refer to it UBI as shorthand because it's easier. And then you'll see we provide actually a bunch of information about these container images. So in this case, the most important things I'd point out is we provide a bunch of different tags, and we grade these tags. So containers age like cheese, not like wine, is what I like to say. As they get older, they become less cheese is not so great, a month old cheese, two month old cheese gets less great, wine gets better, but cheese gets worse. And container images, basically as they get older, they're read only, they're static blobs essentially. And so as they age, more and more CVEs and problems are discovered with them. And so often, there will be security problems with them. And so what we do in the container catalog is we actually rate them and kind of give you a shorthand way to figure out if these are container images that you should or shouldn't be using. And generally I try to, I recommend people should always kind of try to be going for a goal of A, right? So I just want to kind of show that we actually have this tooling, this helps you kind of figure it all out. I'm going to actually go back to the terminal and then we're gonna start using these UBI 8, the UBI 8, which is based on rel 8 image. So fine, we've went up to the container catalog, we've realized that latest tag has a grade of A, we're happy, we trust that we think this is good. Cool, let's run one, right? So all right, I'm in a container, this is easy, all right? In a Red Hat, if you look inside the container, it looks like I'm in a Red Hat Enterprise Linux box. That's cool, this is Red Hat Enterprise Linux 8. I can see a more extensive version of this with OS release. You can see a whole bunch of things, different pieces of metadata about this operating system. Okay, but this is kind of boring because what is the point of running, there's a saying back in the day, nobody runs an operating system just to run an operating system. What's really important is the application or the workload that you're running on the operating system, right? So now we start to move from fine, I found a quality base image, but now we're into run, we got through run, just running a base container image. But now what we really wanna do is we wanna build upon that. We wanna start to build more value on top of that. And so we're gonna actually use a little Docker file here that I created. And notice here, we're gonna do a podman build. We're gonna tag it with this special tag here that you're seeing, quate.io slash fatherlinux slash UBI dash sharing. And then the dash f just means use this Docker file. So we just go through a little build process here where if you notice in step three, we just add a few utilities. I wanted to add a few utilities to the container image that I can kind of demo it and we can get into there and muck around and show you kind of some networking, et cetera. Just make it kind of useful. If it was a full fledged application, you would obviously build more on it. Now let's see, when we're done building that, okay. We do a podman images, we can see locally here, we have this container image that's saved locally in my cache and you see it's latest tag and it was created three hours ago because actually I'm just recreating an image that I already had there because I ran through the demo before this. But you'll see now, once we have it cached locally and we say, okay, let's imagine that I've iterated on that a few times and added enough stuff that I feel like there's value here that I've created. I wanna go share this with somebody. How do I share it? Well, you can't share it locally from your laptop. You have to push it somewhere, right? So you'll notice this podman push command. We're actually gonna push it out to a registry server called quate.io in the my user account and this is actually a live image. You could go pull this down and use it today. And since I was using Red Hat Universal Base Image, there's no end user license restrictions on this. You can go use this for whatever you want. You can use it for open source pools. You can use it for products if you're a ISV or a partner of Red Hat or even if you're not a partner of Red Hat, you're just some ISV that sells software. You can totally go use it, UBI. But once you push that out there, now this is actually live for anybody on the internet to use. But really even that hasn't gotten us to where we truly wanna be. How do we deploy this? How do we do something real with this, right? So the question is, in production, there are typically like scalability and high availability requirements, right? Like you can't, running it on a single node is probably not what we wanna do. I mean, a single node for a small web server for maybe my personal blog, that's no problem. But as you get into real world workloads, you need something that provides high availability and scalability so you can scale up, maybe up to 10s or hundreds of containers, maybe in thousands of containers. So Kubernetes has kind of hands down won this race of container orchestration and providing this high availability and the scaling capability. And so I'm gonna show you OpenShift, which is Red Hat's version of, it's Red Hat's distribution of Kubernetes. And to do that though, how do we get there? That's the question, right? So I would say a lot of people kind of sag, they kind of get, they kind of lull and they get a little bit scared when you go from Podman to Kubernetes because Kubernetes has a lot more concepts and things. But I'm gonna show you that we can actually make it really easy to do this. We can use a feature in Podman called Podman Generate Kube. So to do this, I'm gonna show you a very simple container here. So you see, I'm running, I'm just running that container image that I created. I'm gonna run bash in it, but I'm running it in the background. That's what that dash ID means. It means detach. I mean, don't have it connected to a terminal. And you'll see, okay, that little tag that we got back, that big long string of numbers and letters, that's the identity of this container that we just created. We can see it running. You'll see here, if we do a Podman PS, we can see it running. And then this is where the magic happens. We do this Podman Generate Kube. I'm gonna call it Tron because the entire theme of my talk was around Tron. We're gonna write it out to that file and then we're gonna take a look at it. So if you have ever kind of taken a foray into Kubernetes, you'll notice this is a lot, you're biting off a lot more to write out this entire file, right? Like it's not super complex, but it is a lot harder than just typing Podman Run. But actually I was able to just type Podman Run, export and get something that I can basically go take over to Kubernetes and run it as is. And so you'll see in here, this is a pod definition. If you look under this kind to some metadata around the names, but the important bits in here are you'll notice it's using the same image that I was using in that Podman Run command. It's using the same name that I used and it's actually using the same command that I used to run. So you'll see the command is bash. Now let's get out of here and then let's actually use this. We're gonna use an environment that I actually have fired up right here called Code Ready Containers. You'll see in this virtual machine over here, I have something called Code Ready Containers. This provides me a full fledged Kubernetes environment and this is basically gonna let me simulate a full fledged production Kubernetes environment. It's only a single node. In a real life scenario, you might have tens or hundreds of worker nodes out on a cluster, but it would look identical. Once you've gotten it into this tron.yaml, you could submit this to a cluster like this with a single node or you could submit it to a cluster that has a thousand nodes. It's irrelevant to you. And that's the beauty of getting to this Kubernetes format. So let's go take a look at Code Ready Containers. You can see we have a single node here. It's been up for a few days. This is version 1.14 of Kubernetes running inside of this. And then let's look inside. We have a bunch of projects. You'll see this looks just like a production OpenShift environment. You can see there's a bunch of different projects. We're gonna create a separate project for this particular demo. And we're gonna create one called Tron. It succeeded, you can see. And we're now actually, it automatically when we create this project, it makes the OC command, which is OpenShift command. It's basically the command. It's very similar to KubeCuttle. It puts us into that project automatically. So now when we look, you can see we have a new project called Tron and we're going to submit, we're gonna use a very simple OC create command to basically use that YAML that Podman created and then submit it to that Kubernetes API. And then we're gonna watch as magic happens. So you'll see after a few seconds, we'll go from container creating to running. So what just happened right now is we actually just ran a command, ran a simple, simple container with Podman, exported it, created some YAML, submitted that to Kubernetes environment. And now in this Kubernetes environment remotely, in this code-rated containers workspace, or in this code-rated containers environment, we have a running container that is exactly the same as the one that we had locally running in Podman. We didn't have to do any of the work of going and writing all that YAML. So let's look at this. You can see when you do an OC described, you can actually see this entire thing. There's a lot more metadata when you run something in Kubernetes. You can see I have an IP address on this network inside. You can see it's running on the OpenShift SDN. But again, the important bits are, it's using that same container image that I was using. You can see here, look, it pulled the container image down in that Kubernetes environment, and it is using the same command that I ran. So basically, this is the same definition of a container that I ran with that simple Podman command, but I was able to run it in a Kubernetes environment in seconds without having to write any Kubernetes. So now let's look, you can see it was running for about 78 seconds. But let's move on to a more advanced use case. I showed you a fairly simple use case just to kind of get your brain around, oh, I can go from Podman to Kubernetes really easily. But what if I'm gonna do more complex stuff? Well, Podman also has the ability to run what are called pods. So a pod is a way to run multiple containers while sharing namespaces. And if you're not familiar with namespaces, namespaces are little pieces of the Linux kernel that are essentially virtualized. And so each container thinks it has its own version of these data structures. So for example, if you look at the process ID table or you dump the contents, as we say, of the process ID table on a system, you will see all the processes on that system. But if you do it in a container and that process ID table is virtualized for only that container, you'll only see the processes that are running in that container and we call that a namespace. So we're gonna create a pod and what that's gonna do is allow us to create all these namespaces. Then we're gonna add a container to it called Flynn. And if you remember the movie Tron, Flynn was Jeff Bridges' character. This is one of my favorite movies of the kids. So I like to reconstruct it. And also by the way, the recognizer was that very large hovering kind of intimidating vehicle that would fly around and smash people with its flat feet and kill the programs that were loose on the grid. We're gonna add Flynn and we're gonna add Bit because we don't want him to be alone in the recognizer as he's hunting through the grid looking for other free programs. And then once we have, now what we have here is we have a pod and then we have two containers running inside that pod. And this is a really cool command, this pod list. We're gonna show you some really interesting things here. So this over here is the pod ID. You can see it's running. It's been up for 45 seconds. But what's really interesting here is they're sharing all three of these containers. You'll see them over here, container name. It's called bit is here, Flynn is here. And then this infra container, this is what is called a pause container. It's an empty container that doesn't really do anything. It's actually just a process that sits there and hangs. It does nothing other than keep those namespaces open so that we can then add those other two containers later. This is the exact same structure. This concept of a pod is what's used in Kubernetes. And in fact, in Podman, we just implemented a version of this. But you'll see these three containers all share the same net namespace, IPC namespace, C groups and UTC. So essentially, think of this as these containers can all see each other's memory and they're kind of sharing a virtual environment together. So let's take a look at Recognizer. This is internal JSON structure that lib pod, which is the underlying library for Podman users to keep track of a pod. So you'll see here, there's three different containers running. There's the pause container and then there's two IDs for the different ones that I created myself. And so if you do a Podman PS, that will show us the containers that are running. You'll see one is, you see I have the Tron one that I ran originally and then you have Flynn and Bit. But Flynn and Bit are together as part of this pod. But the beauty here is, I don't have to do a lot of work to take this exact pod that I've constructed with three simple commands on a single node here on my laptop. I can now use the same kube generate command. I use this, I'm adding a little more stuff here. I'm adding the dash S, which is actually gonna go create a kubernetes service. And then I'm actually using that pod as the name. So I'm actually just gonna grab everything that's in that pod, all the containers that are running, and then export them into this recognizer.yaml. And then we're gonna take a look at that. Now you'll notice here, this is a much bigger yaml file. This is one that I really wouldn't wanna write by hand to be honest with you. This is kind of hard. It has two pod, it has one pod definition up here, but it has two containers. Here's a container. And you'll see this is in this recognizer pod. And then if we go down, here's another container, flin, here's flin and bit was up there. And then down here, even better, we've created what's called a kubernetes service. And it's what gives us network access inside of kubernetes. So the service layer is what inside at a low level is kind of what lets all these containers talk to each other when they're spread out all over tens or thousands of nodes within a big kubernetes cluster. So let's use this yaml to fire up all these containers basically. So first we're gonna create a separate project and then we're gonna look here. We have the original Tron project that was just the simple one that we just ran a single container. And then we have the Tron Legacy one, which was the later Tron movie. I thought that was my little play on the Tron series of movies. So now in this one, I'm going to add, I'm going to use this yaml that I generated and actually create a much more complex setup. And then I'm gonna use the same OC get pods demand. This is a dash w allows it to just keep watching. So it's literally pulling the kubernetes API and say, hey, tell me when these containers run. Okay, look, just within a few seconds, both of these containers fired up. So let's get out of here. And then let's do it again here, what we did. I should go back and show here. We use this OC describe pod. What we're doing is we're asking the kubernetes API, hey, tell me, tell me about this pod and all these things are running in it. And you'll see got an IP address. Again, they're sharing the net namespace. So all both these containers share this IP address. And then you'll see that like it has the Flynn and bit containers are running inside of the same pod. And then you'll see here, you can kind of see through the log, you know, started Flynn started bit. They pulled the images, both these folder images. And then they were assigned, you know, they got, they got, they got scheduled to the CRC master that happens to be because we have a single node kubernetes cluster. But if this was a large kubernetes cluster with a thousand nodes, we would, we would just, you know, it would get scheduled wherever it gets scheduled in this big cluster. But the level of work for you would be identical. You don't have to do anything. You can literally just do this pod minute kubernetes and then push it off to a kubernetes cluster and let it run. So here we go. Let's go look at these pods. You'll see there's one pod called recognizer. It's been up for 82 seconds. And then the really beautiful part is this OC get service. The beauty here is we've actually given an IP address. We put it on the network. It's even got a port up. Now if we were running some kind of network-based application, this would be all up and running inside of this pod. And if we wanted to scale this up, we could scale it up. We wanted to scale it down. We could scale this up to 10 containers down to one. It doesn't matter. We can do all that because now we have all that, all that capability in the kubernetes API, which is much more powerful than just standalone podman sitting on a, you know, a single node. And then as a bonus, I'm going to give you some bonus information. This is a little known capability of podman. There is a podman generate system D. So I'm going to go back to the simple tron example that I did at the first at the beginning. That was one container, right? But when we run this command, what we get is actually a, there are times when we don't want to go all the way to kubernetes. We just want to run a simple service locally on our system. And it would be really nice and easy to start out, you know, a single container with system D. And it just so happens to be that if you look at this, here's a unit file that was generated. I can literally copy this unit file or podman is actually even nicer to you than that. You can actually just run the dash dash files option to this sub command. And it will actually just generate a file and dump it in the directory. It will actually generate a service file for you. And you can copy this into the directory where system D wants to find it, reload, let system D find it. You can literally do a system D enable and actually run this. You may be asking yourself, well, why don't you just show us that Scott? Well, the reason why, and I'm going to clean up, I'm going to let this clean up and then I'm going to show you why. It's a really interesting thing here that I've been doing that I didn't tell you about. So that's the end of the demo. I've cleaned up everything, but notice where I'm at. I am on a terminal shell and I am running as Father Linux. I'm not running as root. I did this entire demo. I did everything that I just did here as a regular user. There was no root involved. If you look at the history of containers, this was never true. We always had to be root on the local system when we were running containers or we had root even if we didn't realize we had root. I don't have actually the ability to go copy that system to unit file into the shared directory where the, I would need to be root. I would have to sue you to do that, but I can still generate the system file and hand it off to my sys admin and say, hey sys admin, will you please go add this system to unit file and go fire up this container every time the system boots? But this is a really powerful thing that I think a lot of people don't quite realize. It's really valuable to be able to run all of this as just a regular, as a developer. I don't want extra root power on my system. I don't want to be running as root because I don't want some hacker tricking me into running some command that destroys my system or hacks me somehow. So being able to build, find, run, build, share and deploy containers as a non-root user is really, really powerful. It's probably one of the most exciting features in Podman, if you ask me. So with that, I'm going to actually just jump back to share a little tiny bit of information at the end here. You'll notice that throughout this demo, I talked about a lot of technologies. I talked about Podman. I talked about Red Hat Universal Base Image. I talked about Red Hat Container Catalog. I talked about Kway.io and Kway Enterprise is actually a registry server where if you want to do this internally and you don't want to share this with the world, Kway.io is out on the internet. Kway Enterprise is something you buy and deploy locally. I talked about OpenShift, which is our enterprise distribution of Kubernetes. And then I talked about co-ready containers, a technology that allows you to run an entire OpenShift environment locally on your laptop. And so there's a lot of different technologies I dragged in, but I showed how easy to use them all together. It's not that hard. It's actually quite simple. And then I wanted to leave with you a few links. So if you're interested in going out and looking at the Red Hat Container Catalog, that's the first link. If you want to use Podman on a Red Hat Enterprise Linux system, you can actually do that for free. A lot of people don't know that. You can go out and get a no-cost REL developer subscription, fire that thing up, run Podman in REL, exactly like you would run it in production. So if you're a developer and you want to run something exactly like your sysadmins run it so that they will accept that thing into production much easier, you can run REL locally. And then when you hand that container off to them, it will just, you know, they'll be happy with it. They won't be annoyed that it's something that you download off the internet. It will be, you know, something that's enterprise ready. Finally, again, if you want to run Kubernetes locally, you can go out and check out co-ready containers. Super easy. It takes like two commands. That VM that I showed you that had co-ready containers in it, that takes like two commands to fire up. And then finally, if you're interested in my demos, you can go out here to GitHub. I've actually saved all the stuff out here. Here's the Podman, you know, all the YAML that I generated. And then if you really want to see the start script that basically is the entire demo that I did. So if you kind of want to go back through, maybe I went a little too fast, go through and you can run those yourself, you know, with Podman. So with that, I think I will turn it back over to Burr to see if there are any questions. All right, there are some questions, Scott. We actually had a ton of interaction. There's a huge number of people on the line today to listen to this talk. So it's super popular. One, could you quickly and one more time, you know, really nail the, what is, how is Podman different than Docker? That was one question that came up. How is Podman different than Docker? Why is it better? Just articulate that one more time. Yeah, I didn't dig into that deeply because I was walking through a use case, but Podman is a really elegant architecture in that it's just a single command. You can think of Podman as very similar to Bash. Like when you fire up Bash, you're just in this terminal, right? You type commands and you don't realize what's happening, but Bash is talking to the kernel to go create these processes on your behalf. Every command you type is a different process. Podman is like Bash, but instead of creating regular processes, it creates containers. And so basically when you run anything with Podman, it's like using Bash to create other processes except that you're creating actual containerized processes. And so the beauty of Podman is that you can run it as I showed there as a regular user. You don't have to have this client-server interaction where you have this daemon out there and then you have a client and then you have to go talk to the daemon. Then the daemon has to go talk to a registry server. You simplify the interaction. And there's a few other places where this really shines. Like when, for example, you're doing remote inspection of a registry server, Podman is going directly out and talking to that registry server. And other tools that Podman leverages, one called Scopio in particular is really nice because it can go directly out to a registry server, copy a container image from one registry server to another registry server without ever actually copying it locally on your system. And so again, it doesn't need root. It can just like move these images between registry servers. As long as you have access to these two registry servers, you can do that kind of thing. So the architecture of Podman is really elegant. That's probably its biggest capability over something like Docker. But on a service, it's actually quite similar to Docker. It has a very, very similar command line interface. And I think that's what people noticed when they saw you doing the demo. They're like, hey, that looks a lot like Docker. How is it different than Docker? Another question that came up from Ibrahim, he wanted to know if the Podman generator of the cube files was using the same technology that Quarkus is using, and there's actually J-Shift that's part of Quarkus and Decorate that's part of Quarkus. Are we sharing and reusing this cube file generation technology across these different projects? I don't know the answer to that, but I don't think so. Ours is written in Golang. I think that's written in Java. So I think they're different. Yeah, I think so too. So that was my response. I'm pretty sure they're different, but I thought it asked. Yeah, I'm pretty sure they're different. I mean, our sprint team worked on this in Podman and we probably created this, Brett Bode worked hard on this in the last four or five, six months. I've never seen any interaction with a Quarkus team, but that's cool if they're doing something similar. That's really cool. Yeah, yeah. I use the other tools myself to do the same kind of thing. Now, Dwayne had a great question right at the very beginning of our session. I want to make sure we get to it and we're basically out of time here, but he's having trouble with his REL7 box and using Sudu. He always finds that he has to do Sudu to make Podman work. Do you have any insights on that? Yeah, I do. I have a lot of insights on that. So the short answer is, are you updated to REL77? Because in REL77, you should be able to do it as a regular user. Rootless should work out of the box. Technically, it is tech preview, so it is not guaranteed to work, but I still use it all the time. I use Rootless. I've actually gone from the point where I'll fully admit, six years ago, I started with Docker. About a year and a half ago, I started using Podman a lot because I'm on the team and I'm like, I should start using it. We use Docker and, you know, at that time we were using Docker and Podman, but I'll fully admit as like any user, I had little inhibitions, little butterflies in my stomach and I was like, I'm not quite ready to go to Podman. I still wanted to have Docker installed and it's like feel warm and fuzzy and I kind of felt secure. And then after a while, I was like, I guess I really don't need Docker anymore. And so I started using Podman daily and for about a year and a half, I haven't had Docker installed. Then in about the last two months, I went from, I used to run Podman as Root because I was just used to running it as Root. And then I started running it Rootless more and more and more. And now I've realized in about the last two months, I don't run it as Root anymore. That is absolutely possible in RHEL 7.7. It's possible in RHEL 8. And we're targeting generally available in RHEL 7.8 in RHEL 7.8 and in RHEL 8.1. So if you're using CentOS or something like that, you're going to have to wait a while because it'll be downstream, it'll take a while to roll down. I've noticed some questions in the forums and things where people are asking about CentOS. The first thing that I'd say is update to the latest one. If you can get to 7.7, you're going to be able to use Rootless. There's one downside to the Rootless in 7.7. It uses what's called the VFS driver. And it will not, so you will use up a lot of disk space and actually the containers will run a little bit faster. They're actually a little bit faster in real-time but they do use up more disk space. When we release RHEL 7.8, we're going to use what's called use overlay. So it's a way of running overlay FS in user space so that regular non-root users can do this. Down the road, we're looking at other technologies like ref links and all kinds of other things that we might use, but for today, use overlay is going to be the thing. And I would say keep your eyes peeled in RHEL 7.8. You should be seeing that drop. Okay. And we are now out of time, but one last question I think we can get to is what about Docker Compose? What's our position on Docker Compose? Does it work with Podman? Doesn't work with Podman? What's the answer there? The short answer is we keep looking at it. We keep trying to decide if it's something that we could support well. There are other upstream projects that basically are trying, there is like a Podman Compose. There's other upstream projects. And the short answer is we'd welcome other people to take that on if they're really excited about it, but it's not an open standard. And it's not the API that seems to be winning long term. I personally think that Kubernetes YAML that I showed you, I didn't show a feature that is called Podman Play. So there is a generate and then there's a play. I can actually play Kubernetes YAML with Podman. So I can like take the Kubernetes YAML, export it from OpenShift, run it with Podman. And then as I showed in the demo, I can generate it locally with Podman and then run it in OpenShift. I actually think it's much better to use that Kubernetes YAML as the definition that we share around to each other to develop as opposed to Compose. And people will say, well, the Compose YAML is really easy and I can write it by hand. And I get that, I totally understand that, but you don't have to write it. Like Podman exports it for you. So like why even write it at all? I would say just export it, hand that to somebody else, let them play it and like forget about writing YAML and JSON files. Like it's just not worth it. That would be my, that's my personal view on it. Well, unfortunately we're out of time. Thank you so much, Scott. Awesome demonstration and great way to present this topic. We have a lot of more questions where we just simply don't have time to get to them today. I apologize for that. We'll have to come up with a future presentation maybe that's more of a Q and A type session with you. That would be a lot of fun, I think for people. And we can advertise that widely for people who really are more interested in diving deeper into what's happening with system D, what's happening with when I'm at port. So I see those questions guys and I apologize, we just want to have time for today. Time for today. But thank you so much. Thank you for being here for another Dev Nation. It was a great time, great topic. I learned a lot. Hopefully you all learned a lot as well. And Scott, awesome job. Thank you so much.