 And today we have with us Peter Hunt, maintainer of the Cryo Project. Peter is great to have you on the show. Hello. Yes. Thank you for having me. Yeah. And as we all know, a CNCF has announced the graduation of the Cryo project after a long, you know, I think the project was created back in 2016. It was contributed to CNCF in 2019. We'll talk about that. But what I will talk about is, first of all, congratulations. And second is that, can you talk about the idea behind Cryo Project, why it had created because back in those when Docker container, they were like kind of a dominant player. And you know, a lot of things were done like OCI was created to overcome some challenges. So talk about just walk us through history because we tend to forget it. Totally. Yeah. And it's a deep history too. So, you know, as we all know, it all started with Docker in the beginning of 2014-ish, you know, when it, you know, around the beginning of Kubernetes as well, Docker was built into Kubernetes through the Docker shim. And the Kubelet spoke directly with Docker. At the time, Red Hat was also contributing to Docker. Basically, their container strategy saw the promise of Docker and Kubernetes and jumped on it early. Right at the beginning, there were some challenge, some like differing opinions in the way that tools should be specialized in the container ecosystem. So while Docker, you know, comprises a bunch of different projects to Docker server and the Docker client, you know, and also has a bunch of different use cases that it's for, you know, the end user who is debugging their containers all the way to, you know, a cluster admin who's, you know, deploying containers in production. And Red Hat early on thought that it might be useful to break apart those kinds of use cases and have separate projects for each of them. All the while, also a lot of Red Hat's priorities were, you know, in supporting Kubernetes and in supporting, you know, production containers in a way that's secure and reliable as possible. And so Red Hat began a set of projects which don't really have a great umbrella name, but include, you began with Scopio, which is just for moving images between registries and then cryo came next, which kind of took some of that work that Scopio had begun. And then also built, you know, extended it to being able to run containers in production specifically for Kubernetes. Eventually the Podman and Builder projects were began as well that are for, you know, running the deploying containers and, you know, single nodes or in, you know, building containers. And each of these projects, like ultimately fulfill the same scope that Docker does still today, but by breaking them up, they can each specialize and have different configurations by default to sort of specialize to their individual needs. So that was a lot of the motivation for the beginning of the cryo project that it also conveniently was able to fix a couple of the other, you know, small little nits that the, you know, red hat, you know, people, the engineers that began the project had with, you know, the way that Docker interacted with the Kubernetes ecosystem. Version matching was kind of a challenge, you know, figuring out which version of the Docker server was compatible with which version of the Kubernetes, you know, Kubelet client for it. So cryo kind of fixed that by version matching. So the version of cryo matches directly with the version of Kubernetes. They have a one-to-one relationship. Cryo aims to be secured by default, you know, production system, so it drops capabilities and it, you know, disables some things and enables some other things that didn't come out of the box in Docker. So it allowed basically to laser focus on the production Kubernetes use case, which, you know, began it and has kind of persisted through cryo's lifetime. Now I'm kind of curious that red hat, you know, you folks do a lot of open source, I mean, your champions, you know, everybody talks about the red hat story, but a lot of red hat products, projects which are like kind of owned and controlled by red hat, but this is one of the few projects that red hat contributed to a neutral foundation. What was the idea behind putting cryo into CNCF? Back in, you know, 2018, 2019, this was actually right at the beginning of my involvement with the project. Basically, the CNCF obviously as an umbrella organization, you know, matched sort of our target audience pretty well. So at the time, container D was just about to become a graduated project. Kubernetes had been a graduated project for a little bit. The notion of the tiers in the CNCF had kind of just been created. And, you know, I think a value proposition that the CNCF posts to the cryo community is more visibility. And we've definitely gotten that through, you know, appearances in cube cons and, you know, some of their marketing efforts. So I think, you know, being posed as, you know, I wouldn't, like as an alternative to the industry standard, you know, Docker and then, you know, bi-association container D kind of have been historically considered to be the industry standard for the, you know, container runtimes across the board, including in Kubernetes. And I think as a team, our team, you know, wanted to, you know, make a claim of our stability and also, you know, of our viability in the space. And I think the CNCF kind of posed as a avenue for us to make that claim for everyone to hear. And I believe that that's been the case. What does graduation really mean for projects like cryo, which are being used? Just talk about the importance, significance of graduation, not just for the project, the whole ecosystem, folks who are leveraging it, like the maintainer community, folks like you, and of course, the organization like CNCF. Yeah, I mean, I think graduation, it definitely, it's like, it's definitely not a symbolic gesture. There's a lot of work that goes into it, but I think at a certain point, projects, like there are so many steps to the graduation project, process that projects end up kind of proving their viability naturally through the process and then in their stability. So I really think that cryo has been like graduation worthy for a long time, but because of all of the steps that are involved, CNCF wants to be very rigorous about who they consider to be a graduated project. And because of that, their standards are very high for the number of like the sort of all the documentation needs that are needed in the security audit. Like all of these things required a lot of work to kind of corral a bunch of people or like the whole process of graduation from start to beginning kind of took us like a year about finding someone the CNCF to take us on and going through the due diligence process. So it, I would say for a project that has reached a certain level of stability, like I think projects know when they're ready. And then it's just a process of working through all of the pieces. A lot of our time was spent looking for a security audit. That was kind of a challenge that we met along the way. And ultimately, you know, through CNCF and OSTIF, they were able to find us some two companies to help us out with that. And that was a huge help and that took us, you know, really most of the rest of the way and then all of it, you know, all the rest of it kind of was just finishing up the documentation and then letting the process marinate and the CNCF, TOC, technically technical oversight committee kind of work through the process. Can you talk about what kind of the streets? Of course, I would not ask you to name any specific player because, you know, they're all important. Are leveraging Cryo today? We have, so there's a healthy mix of end users and, you know, cloud providers, so, or, you know, platform providers. So I would say OpenShift, Red Hat OpenShift is probably one of the larger end users of Cryo, but that's just, you know, because it's a platform that provides it as the container runtime by default and really, you know, the only one that's supported on Linux nodes. So, but the other, I mean, there's a number of companies that are listed in our adopters files and users, you know, big players like, you know, if I can name them, I think publicly, but like, you know, the Reddit and Lyft and Adobe, you know, players like that who see the value proposition in having a container runtime interface implementation that's built strictly for Kubernetes and have benefited from kind of adopting that. And then cloud providers, you know, IBM and Oracle both provide Cryo as an option or as the default runtime in their cloud environments as well. So, you know, we have kind of a mix of like, you know, end users who have adopted into it and then, you know, platforms that have provided it. Of course, the project was created by Red Hat and contributed to CNCF. Can you talk about what kind of community is there? How diverse is that community around Cryo project? I will be honest, a large portion of the contributors are Red Hat and that's by nature of kind of Red Hat's investment in the project, sort of like its strategic alignment around it and its sibling projects that I mentioned earlier. But that's not like a choice of the Cryo community. I mean, like I personally, and then by extension, the Cryo community, like we have worked, you know, towards trying to increase people's involvement in it, you know, asking people in issues to help out if they want to or, you know, pushing for other companies, you know, for the first handful of years, there were a number of other companies that were contributing to it. And then, you know, some people, you know, just moved away or changed priorities and stuff. There, Sousa had for a long time, a lot of investment in the Cryo project. And then, you know, just project priorities changed. And now Intel is probably our largest other contributor and partner in sort of the process of supporting the Cryo. But, you know, that said, like none of this is the desire, like I would love it if we had a more diverse, you know, maintainer community. I think the CNCF and, you know, Kubernetes ecosystems are kind of hitting a maintainer sort of shortage right now. Like, you know, I think a big story recently has been at CD kind of just like needing more contributors than like, you know, companies are able to provide. And so luckily the crowd community isn't at that position. We still have pretty good investment from enough people to keep the community going. But, you know, we definitely are always looking for more help and I'd be personally happy to help anyone start up in the community if you have interest in it, especially if you want, you know, to use it in-house or sell it to someone, you know, I'm happy to help guide that process, so. What are the things that are in your pipeline? I'm not asking about the exact pipeline or the exact roadmap, but what are the things that you folks are working on that, hey, these are the things that we are working on going forward? I mean, our main priority has basically been the same since day one. Like, we are looking to be a container runtime, you know, interface implementation that matches exactly to the Kubernetes CRI spec. So a lot of our priorities end up, you know, working in SIGNode along with the container D community to define what the CRI is and means and does and, you know, conforming to that. That's like our main priority. Outside of that, you know, we have a couple of initiatives, you know, there are some features that like, you know, are slightly outside of the Kubernetes world but obviously still relevant. You know, SIG Store integration is a very hot one that we're kind of working hard on right now. We have, you know, there's the container monitor, conmon, which we're rewriting and rust from C. And that's kind of an exciting project that we're working on, sort of, and then just general stability and, you know, bug fixes and, you know, we just want to be the most performant and reliable container runtime for Kubernetes. And so we're steadfast on that goal. Peter, thank you so much for taking time out today. And of course, first of all, thanks for sharing the whole history, the original of the project and also how it's been used today. Thanks for all those insights. And I would love to chat with you again when the new updates, the project. Thank you. Absolutely, yes. Thank you so much for having me and also for everyone for watching. And thank you for using CRIO, you know. I, as a maintainer, I think I can speak on behalf of the maintainer community. We're very thankful for all of the support and we're very thankful for graduation. So, you know, we're excited. The future is bright in the container and Kubernetes ecosystems. And I'm only looking forward for more innovation and more work altogether. So thank you very much.