 How did everyone like that arm-sponsored coffee break? They didn't actually ask me to say their name that much. The gentleman who is here from ARM, this is a bonus. So our next speaker is Dusty Mabe, and he is going to be talking to us about atomic. Right? You want this one or you want that one? I want this one. And I'm going to stand over here to the side so I can actually see, I can't do anything with my left hand. Okay, so my name is Dusty Mabe. I'm representing the atomic working group, which has meant a lot of different things to a lot of different people. Langdon just asked me to clarify. I am not currently representing the cloud working group up here right now. The cloud working group is the one that delivers the cloud base image, which is essentially the classic login to your system and install RPMs or use cloud in it to kind of boot it up. He wanted me to clarify a lot of other things, but I don't necessarily build that into this talk. So I'm representing the atomic working group. What is the atomic working group? We've kind of been three different parts up until this point. Obviously there's the atomic host part. There's also the container run times part. So we have a team of people that work on Docker or Podman or other container run times. So how do you run containers on your host? And we also have a group that works on essentially application containers within Fedora. So helping take applications that are traditionally delivered by RPMs in Fedora and packaging them up in containers and putting them in a registry that Fedora users can then download and use. So let me start with the containers teams updates. So first of all, we've had a lot of work done here in the containers teams. And now each of our tools has its own little avatar. So MoDuffy created a container run times coloring book, I believe. And essentially what we have is a different avatar for each tool. We've got Podman, Scopio, we've got Builda, we've got Cryo, and a little guy over there for OpenShift Origin, which is pretty awesome I think. So I decided to include that in this portion of the talk. But really what has happened with the containers teams in the past six months, I asked Dan Walsh to give me kind of a condensed version and he gave me two pages of notes. So that's what we ended up with. I essentially took that and tried to condense it down into something that was consumable for this audience. So first off, we'll start with a tool called Cryo. Cryo is essentially a container runtime for Kubernetes as version with Kubernetes and release with Kubernetes. So for example, if you want to run Kubernetes 1.11, you would use Cryo 1.11 and another version, which is really nice because you know that it was tested with Kubernetes 1.11 and it's more likely to work and you don't have to deal with version mismatches and all that, which can be quite troublesome as we found out when trying to pair it with something like Docker. So as version with Kubernetes, release with Kubernetes, we also have OpenShift Origin that is trying to target Cryo and only target Cryo at this point. So using Cryo as a runtime, we're currently running OpenShift Online, which is essentially a place where you can go try out OpenShift if you want to just kick the tires with it and see if it's something that you could use. So it actually runs on top of Cryo now and we also have that running in Microsoft Azure for Cata containers. So Cryo is running in the wild, which is kind of cool. So other things that they've done in Cryo in the past six months is offer better security through they added a rootless mode. They've added no dev mount, so if you had a file system that was mounted with device nodes on it, the kernel will ignore that now. And they've added some ability to control capabilities a little better for Cryo containers. The next tool is Podman, which is essentially a way to run local containers on your system via CLI or API. It's essentially a Docker equivalent. One thing that we've done there is added the ability to actually build OCI images with Podman. So previously Podman build was not a thing, but they've actually coordinated with Builda and now you can run Podman build just as if you had done Docker build and it will actually create an OCI container on your local system that you can then push or pull from a registry, which is quite nice. They also added a rootless mode. So if you've ever had an issue where you wanted to run Docker on a system but you didn't want to run it as root, you can now do that with something called Podman, which is pretty awesome. They also did some work with rootless network namespaces, which is actually something that's been pretty hard to do in the past. They use a technology called Slurp for net namespace. And they added user namespace support and remote API via var link. This has enabled them to create essentially Python bindings or integrate with tools like cockpit. Builda is essentially a tool that you can use to build OCI container images. It's the back end for Podman build. They also have added layer caching now. So previously if you ran Docker build, you would get caching for every layer if, for example, part of your Docker file had not changed. You now get that with Builda and with Podman build. And they added rootless container builds. So if you're an unprivileged user on a system, you can actually just inside your home directory create an OCI container image, which is like, I guess, more or less a sophisticated version of a tar ball, which you theoretically should not need root for. So they added it so you can do rootless container builds, support for user namespaces again, and integration into OpenShift. So if you did any builds in OpenShift in the past, you were running on top of Docker build essentially. Now they have that integrated into OpenShift a little better. So now you're using Builda instead of Docker build. All right, condensing this down into a few other things, Scopio, container storage and containers image, which are libraries that Scopio uses. These are essentially used to push and pull container images from registries. So they added rootless support, layer support, better security, compression, et cetera. Another thing to note is a lot of upstream projects are now starting to use these tools like these libraries and Scopio itself. OpenSusa happens to be one that we're collaborating with a lot there. So this kind of shows you a little bit of the health of the project. Having different upstream communities work on these tools and use them is a really good thing. Okay, so application containers. So we have a thing called registry dot fedora project dot org, which is where you can go grab some different applications, you know, Postgres or, you know, we've got a whole list of them here and then Cache D, HTTPD, et cetera, et cetera. We have had this ability for a little while, but it's kind of been more of a, you know, come to the working group and try to figure out how to build it in a candidate registry and then figure out who to talk to in order to get it released. So Clamont's been working on actually making this like an official thing within fedora so you can get container updates in Bodie. You don't have to, like, talk to some person in release engineering that you might not necessarily know at the moment to try to figure out how to get it released because the current version of this release has a bug in it, et cetera. So he's been doing a lot of good work there. He's also been working on building flat packs using our tool that builds these container images called OSBS. So I think it was mentioned earlier that we want to deliver flat packs in fedora. And so he's been working with O, and I think they're on making that happen. Both of those are in staging right now, so they should hit pretty soon. And the other thing that's been working on is multi-arch container building at OSBS. So actually building those applications for other architectures, not just 64-bit AMD Intel. Okay, so he actually sent out a, I don't know, call for something, call for interest recently on the development mailing list. And actually got a lot of interest in people wanting to join the special interest group for containers. So there is a session later this week on Friday, I think, August 10th, whatever August 10th is, I think that's Friday from 1.20 to 3.10 p.m. later, I also advertise another session and I use 24-hour format time, so I'm keeping everybody on their toes. And it is mysyn and ratable, I don't know how to say that, but that is where that will be. So if you're interested, you should definitely join that session so that we can actually get more application containers within Fedora and help knock down some of the barriers there that people are having. Okay, here. All right, Atomic Host. So around the Fedora 28 time frame for Atomic Host, the Atomic Host community has been really growing and we've had a lot more engagement in the community for people that are interested in the technology and interested in using it and interested in the unique features that it has. One other thing to say is the RPMOS tree technology itself has really been catching on. So for example, we actually have two other additions that are now using RPMOS tree underneath. That's Fedora IoT, which I think Peter will talk about. And then Fedora Silver Blue, which Matias talked about earlier. So both of those are using RPMOS tree underneath, just delivering a different package set and packaging it up a little different way and delivering updates on their own cadence. Also in the Fedora 28 time frame for Atomic Host, we started shipping Podman by default. Podman's pretty new. It's made a lot of progress over the past six months. And definitely try that out if you haven't yet. Also automated updates. So this is something that we did not have for a long time. And Jonathan Laban from the Atomic team started working on that. And now, for example, your system can check for updates automatically without you having to type RPMOS tree upgrade or some otherwise script that via Ansible or some other way. We also have a unified server-side OS tree repository, which means when you are pulling content from Fedora, you only need to look in one place. Previously, we had a different repository for every release of Fedora. So Fedora 25 and 24 had their own repositories. Now it's all in the same place. All the different architectures are in the same place. And then also Atomic Workstation slash Silver Blue and Atomic Host are in the same place, which means that if they share any common files, which is likely, they'll also be deduced. We don't need to store that many, many times. Multi-arch. Currently we have AR-64 and PowerPC-64 Little Indian architectures with Atomic Host. We've been releasing those at the same time that we released the 64-bit AMD X8664 OS tree. So those get released at the same time and have some level of testing, not quite as much as the 64-bit Intel, but we've been proud to actually offer that as well. And those get shipped every two weeks, and I'd like to thank everybody who helps enable that because we've automated a lot of stuff, but it also still takes some manual work. So I'd like to appreciate everybody who helps us find issues, report issues, and fix problems as they come out. So what is the future of Atomic Host? Is the big question here, and I'll take a side detour, which is to say, Matt mentioned it earlier, but Red Hat acquired CoreOS earlier this year. I actually saw this exact tweet when I got home from DevConf, you know, right about the same time that I got home from DevConf. And this is actually really great because the CoreOS team, the CoreOS company, basically has or had, I don't know which term you necessarily want to use, like really excellent engineers, a really great open source philosophy, a focus on security, and also a vast community and user base. They really aligned well with a lot of the things that we believe in Fedora and we believe at Red Hat. So I was really happy to see that they had agreed to join Red Hat and to join our community. So one thing that I'd like to say is if you meet any of them here or, you know, virtually to welcome them into the Fedora community and to make them feel like this is a great place to be because it really is and we're really excited to have them with us. Okay, so I'm going back to Atomic Host now. So in the Fedora 29 timeframe, Atomic Host will continue on for Fedora 29. We'll have regular releases until Fedora 30 comes out and at that point basically we'd like to move on to Fedora CoreOS, which is the new thing that we're going to have. So the reason for not having a lot of new features or work in Fedora 29 is because we're figuring out what Fedora CoreOS will look like exactly and trying to build the community there. So Fedora CoreOS. So the goal here is basically to merge the Container Linux and Atomic Host communities into one and also, you know, kind of take an opportunity to revisit the design goals for each operating system, you know, when they were originally designed and see if there's things that we want to change or improve upon. So that's essentially what we've been doing and what we will be doing for a short time period for the next, you know, four to five months or so. And then the goal is that we basically release Fedora CoreOS officially for Fedora 30. So that's why we'll have a Fedora 29 Atomic Host. And I'd really like to ask people to get involved. We have a forum mailing list IRC channel, issue tracker weekly meeting. So we basically got the framework for a good community there. We've had a decent level of engagement already so far. And I have a link up there to our issue tracker, which is where you can essentially click through to find the mailing list or forum or IRC channel and all that. It's hash fedora dash coreOS on FreeNode. And we also have a talk tomorrow. Me, Benjamin Gilbert and myself, Benjamin is from the Container Linux team, he does a good job representing all of their interests. We have that talk tomorrow at 2.30 to 3.20, 14.30 to 15.20 and Hamburg. So come visit us. Who's next?