 This is Jason Porter with the Red Hat developers program here with Dan Walsh, and we're going to be talking about containers and Kubernetes. Thanks, Dan. Yeah, hi. Thanks for having me. What is it that you do at Red Hat? So my job at Red Hat is I lead the container team and the rail-based engineering teams. That means as a technical lead for the group, I have about 30 engineers working underneath me and all things to do are containers at the base level. In REL, we consider our number one customer to be open-shift, so we take requirements from open-shift and Kubernetes to figure out containers. So we do work on things like container run times, alternate tools, atomic host, all things down at the operating system level to service high-level orchestration tools. Okay, very good. So as an end user, what I'm going to be interfacing with as far as containers go from a Red Hat perspective is most likely going to be open-shift. Is that correct? That's the way we prescribe, although we service all workloads. If you want to use standard Docker to build containers, we'll work with that. We're working on newer tools inside of, we have a tool called Atomic CLI that actually allows you to work with containers. It wraps around a little darker and provides additional features, but we're also introducing now a concept of what we call system containers. So if you think about a booting up system, I should take a step back. In the future, we believe that all content or most content will be delivered in the form of a container image. So you store your container images out of a container registry, but even things that happen at early boot time, we want to be able to package those container images. So it might even happen before the container run time. So what happens if something has to run before, let's say the darker demon comes up or Kubernetes and things like that. So what we want to do is package tools up for that use case. So we've introduced a thing called the system container. The Atomic tool can actually work with system containers in that it'll go out to a container registry, pull the image down, store it locally, and actually configure system D to run it. So if you have a container, say you have a piece of software that you want to load a kernel module or modify the actual operating system. Maybe something like an Ansible script or something like that. Well actually Ansible would be configuring these things, but more likely things like setting up a certain software that has to be run inside of VMware or this different software. But even demons that we potentially would bring down, like in the case of Atomic host right now, tends to run as a read only and then you bring down your images as containers. We want to be able to run etcd, FlannelD, which are two core features that have to be running before the darker demon or any other container run time running. So we want to put those as packages container, system containers. And we see in the future that even base regular demons that you might want to run, instead of running them in an orchestrated flow, you might want to run them. So I could envision in the future, a future version of RHEL where you'd run Apache in a container image instead of running it on bare metal as an RPM. So imagine you could do a DNF install of Apache container instead of DNF install of Apache service and things like that. So that's sort of what we're working on and containers run the gamut that you can run in orchestrated mode all the way up to the microservices way. But you can actually run containers as just standalone applications on your host. Got it, very good. So as an end user or developer, where do I go to get started working with some of this stuff? So most of the information we have, most of our software ends up on a site called Project Atomic. So Project Atomic is the great, is a project launched by Red Hat for all of our container efforts that aren't, don't have a formal or different upstream. So Atomic System Contains the Atomic CLI, Atomic Host, are all hosted at Project Atomic plus a whole bunch of other tools. So there's really a ton of stuff out there that we're using now. But we also contribute heavily to upstream container run times and other projects in the OCI world and all that. So Project Atomic is probably the place to go to find out most of the information on this stuff. Okay, very good. Thank you, Dan. Thanks for being with us today. Yep, thanks very much. Enjoy.