 All right. Well, good morning and welcome everyone. I hope you're here for the Container Runtime and Image Format Standards Update. I want to start by just welcoming you all here, and I'm going to turn it over to my esteemed colleague, Steven Walley, and who I'm in awe of. Steven's a sage open source professional. I've been doing this longer than me, but not by much. Take over now. Am I hot? I'm not hot. I told you I could break anything. Light that mic up. Now I'm hot. There you go. Thank you. I'd better step in before Jeff gets his tube carried away here. My name is Steve Walley. I work in the Azure engineering team, and I've just recently gone back to work for Microsoft after a dozen years away. Just to kind of get a sense of folks in the audience, do folks know what OCI is? Show of hands? That's good. And developers? Also good. Operations. Operators, folks like that. Excellent. Thank you. And lastly, managers and other folks trying to figure out what this is all about. Excellent. Thank you for your honesty. Okay. I'm going to turn this back over to Jeff to get us going. Great. Well, thanks. And you've got two Northwest Seattleite residents generally speaking. Any other Northwest folks in the audience? I wore my Seahawks shirt. We won't do the chant, though. I'm going to go ahead and get down to business. So we want this to be very interactive. I'm going to cover the first half and a little bit of the background, and Stephen's going to jump in on the organization and what's going on with certification. And then we're going to have time for Q&A. And with that, how many have heard of a little startup called Docker? Raise your hands. That ought to be everybody in the room, because it was really interesting. If you turn the clock back to around 2014 in the spring, I was at an OpenStack conference, and they weren't presenting at that point, but the buzz in the room was all about, you know, hey, this company Docker, and have you seen what they've done with container technology? And so I got plugged in pretty quickly, but the point I want to make on this first slide is that containers have been around for a while, and I don't represent this slide as exhaustively complete, right? So if I've left off something that's a favorite of yours, I want to apologize right out of the gate, but you can see that FreeBSD started with the concept of jails early on. You had Linux get involved. Sun was certainly a player with what they did with their zones technology. Google started leveraging the heck out of containers back in the 06 timeframe, and obviously did a tremendous amount with that technology to be able to scale out their global ad platform. Red Hat and yours truly IBM got involved with container technology, and all of that led to the point where if you've seen Solomon Hakes talking about this, you know, he's used the phrase in the past, standing on the shoulders of giants, right? Because while hats off to what Docker did in terms of enabling to make containers more approachable and usable by the typical developer, it really is a cumulative effect that's got us to where we are today. So when I met the Docker team back in 14, it was still early days, and yet there was a little bit of confusion in the ecosystem, if you will, because you had this very viral open source project around containers called Docker, and then you had the company Docker as well. And so is it an open source project? Is it a company? How do you sort of sort through that? And I got involved early on and started working with a number of other people in the community around this concept of moving towards open governance. And ultimately that led to an announcement made by Docker, at DockerCon back in 15, the middle of the year, around this idea of the OCI or the Open Container Initiative, a single open container specification that everyone could collaborate on and everyone could agree that would help create some of the foundation of this technology. And you can see the concepts around not being bound to a high level construct, not tightly associated with any particular commercial vendor or project, but a multi-vendor open governance structure, and the intent for this was to help enable portability across multiple platforms. The principles associated with getting this spun up when we worked on the original documentation for it, content agnostic, infrastructure agnostic, design for automation and industrial grade delivery. So there were quite a few companies that got involved early on, and one of the big players in addition to Docker early on was the guys at CoroS. And the folks there had a solid team that was working on this collaboratively and they also had a vision of how to execute. They came up with the rocket project. The last thing that the ecosystem really wanted, though, was to see multiple competing solution alternatives. So the OCI worked to help bring all of that into a greater sense of alignment. And you can see the logos of the other companies involved with the effort. This has been picked up tremendously beyond the initial activities by Docker and CoroS. Mesos, the CNCF with Kubernetes, Cloud Foundry, all of them looked to the OCI as a fundamental enabler of the basic technology. And in terms of who's been involved to date, the contributors hats off to Red Hat, no pun intended. They've been a major participant in helping to develop the initiative. Huawei, Fujitsu, CoroS, Suze, those are some of the top contributors. IBM itself is in the top 10. And that's actually when I got to know Stephen better. He was doing consulting work for Docker on this project, and we started to collaborate not just on the OCI, but starting to think about, well, where are we going to go when this becomes firm? How are we going to try and create some sort of a certification process around this? And what was that? Was that like a year and a half ago? Time flies when you're having fun. Absolutely. So we've got high-level representation of how this is structured. And Stephen, when you first got involved, when did you first, when did the OCI first hit your radar? So I was actually at Hewlett-Packard when this was all happening. And it was one of those things where you ended up in a situation where containers and containerized workloads were going to make such a difference compared to the kind of infrastructure arguments that folks were having in the OpenStack community that working for Hewlett-Packard thought we should be involved. And the frightening thing was it was all based on a single company's technology at the time. Docker really made the container ecosystem usable. And so I was pushing to get HP involved at the initial bootstrap. And Jeff and I have both done enough standards work in our careers that sooner or later it's going to come down to a certification debate. That's where it doesn't matter how long the standard takes or anything else. But sooner or later it's going to become a certification debate. And so as I stepped out of HP Cloud, I ended up going to work for Docker for a year. So, yeah, we've overlapped almost since the beginning of this. Yeah, in fact, how many have heard of the Docker Governance Advisory Board? Six or seven. One of the best-kept secrets in the industry. All kidding aside, in the early days Docker was sort of conflicted because, you know, they wanted to share. They obviously put that out in open source. But they also were starting to think, you know, how are we going to pivot from the startup to more of a going concern or an enterprise? And it's great when Docker came to that realization that they needed to make this contribution that it helped to kick off this project in a more meaningful way. The timeline associated with this, you can see that this has taken two years. And in the era of open source, that's a long time. But in the era of standards, it's really kind of a bit of an eye-blink. Because getting collaborative cooperation and getting consensus amongst such a large ecosystem on such a foundational technology was very, very important. And I think that that's a really important point here. The thing that's been different about the Open Container Initiative from a lot of traditional standards organizations is it's a group of collaborative open source engineers and they're trying to build a specification. And those two things are almost the antithesis of engineers collaborating. With engineered standards, you know, you kind of have to get it right. This idea of doing things on internet time is based on a foundation of a group of engineers 30 years ago took the time to get it right. So we can be moving at internet time. At the same time, when you're living in an open source world and as we've watched these projects evolve and well-run projects are on this cadence of releasing regularly and frequently, that's a different kind of engineering collaboration. So Open Container Initiatives worked really hard to try and find that balance. The fact that they kept the target lean, they started with enormous contributions from Docker for the base technology, both for the reference implementation as well as the overall runtime, it's allowed the group to make really good, quick two-year delivery of those first two specifications. And so just a bit on how the OCI is organized, there's a technical developer community and there's the organizational membership. And we're not going to go into great detail on the org structure, but we can get into that a bit during Q&A if you like. The important part is that we really wanted to, A, have this be a level playing field, right? Right, very much so. And actually, if you bring up the next build out, you know, this is an organization that was deliberately designed to get out of the engineer's ways so that the engineers could be doing the collaboration to build these specifications. Jeff and I are not those engineers. Steven Day in the front row is one of those engineers. So it's, you know, it's one of those things where we were trying to keep a very lightweight organization. That's also one of the reasons that this didn't go to a more traditional standards organization. Those processes can be very heavyweight. And so it's trying to find that balance of creating useful specifications and at the same time letting the engineers get it done quickly or as quickly as possible. Yeah, if you're an engineer that's worked on the OCI, raise your hand. We've got Steve Oh up in front. There's Michael Brown. We've got, it looks like a half dozen of some of the usual suspects here in the room with us. Again, hats off to them. It's taken a lot of hard work to get to where we've gotten to at this point. So this is a good time to start to pivot and get into the details associated with the certification itself. And with that I'm going to stand somewhat quietly and turn the mic over to Steven. So this is the dangerous part because Jeff built these wonderful slides and I start to disagree with. That's the joy of the process, right? Essentially there's two kinds of certifications. There's two specifications. And so there's this idea of an OCI-certified runtime and kind of the portability promise that that would make to folks that are building containers. And then there's that idea of an OCI-certified image. And that is so that this image that's been created, this is the entity of portability, if you will. Part of that lightweight structure that was created under the auspices of the Linux Foundation allowed us to do all the trademark tracking. So there's a collection of trademarks that are listed there. These are trademarks that the Linux Foundation will defend on behalf of the OCI project. So this is one of those things where you can't call yourself basically an open container, sorry, a OCI-certified runtime or an OCI-certified image unless you've survived the certification program. This is the point of this is to actually provide the marketplace information about where to look for things of value. That said, we're also in this place that as we just start to step in, there is a draft of a process. It's a process that you would imagine kind of looks the way you'd expect a process to look like. And this, if anything, was the easy part is coming up with this because, you know, really we're looking at a process that's normal for these kinds of things. You start off with the application. You basically, this is who I am. This is what I want to do. I want this trademark. You take it through and at that point we've sketched in kind of the basic information that we think we want to have. And the next thing you do is you test it. So we're going to go through and test the products against these two things. And I'm sorry, I'm having a hard time because I'm just getting used to having readers for the first time. So I need them to look at the slides. But then I have all of you and I look up and I think, what happened to the audience? It's very disconcerting right now. After you've run whatever the testing environment is, of course, that's when you publish your results. And you have to, what the thinking up till now has been is you're not just publishing your results, you're publishing all of the framework around that so that anybody else could repeat this. And that's the intent of this, is to make sure that this is a highly repeatable system and that can be checked and validated by anybody else. And that's kind of the peer review, is to finally get that certification, somebody within the rest of the organization as a collection of peers will validate that, yes, I was able to repeat this. And at that part, you can actually claim the certification. So that's the easy bit, so to speak. That framework feels like probably everything else you've seen in many different guises. And on the back end of that is this whole idea that you then want to promote your brands that you've earned to the marketplace. Some of the where the debate still lies though is there's two places, one of them is the test harnesses. Work is still ongoing on the test harnesses. And it's, there's good work has been done and it's evolving right now. So these are, we aren't quite ready to announce things yet, but we're close. The interesting debate that I still bring, and I am happy for opinions from the audience when we open this up for questions. Having a certified runtime, I think is kind of the base entry into the game. Having a certified image I worry about. And I worry about this because I've seen this situation in a past life and I'm not going to use the P word today. I've seen this situation in a past life where folks were so excited about having certified operating systems which made sense to support a portability model. But then they weren't, they wanted to, the organization that was running this said and then we'll have certified applications. And that's starting to feel like certified images. And the problem when you look at it from an application perspective is if you're the vendor, you're probably not going to certify if that's a promise to the marketplace that you'll obviously run on all of these places you haven't tested. Because that's the reality of being an ISV. You're not going to promise your customers, regardless of what the platform vendors have told you, you're not going to promise your customers that it's going to run until you've tested it there. And I think that tension needs to be resolved here. So that's part of the debates that we're still having on going inside of the certification work. But it's, that doesn't mean that you couldn't, the World Wide Web has, you know, for W3C as validators. So, you know, this is a valid page. That's a great piece of information. And having that kind of toolset come out of the certification work so that you know that you have a valid image and you should have confidence that this will run on a certified platform is a good thing. So I'm not saying that that tooling doesn't have value and that we shouldn't have that kind of validation. I'm just saying we need to be careful as you step into the nuances of a brand program about exactly what promises being made to customers on the end. It really can be hard to strike that right balance because obviously, if the collective group came up with this draconian certification process, have a lot of overhead, have a lot of conflict, and a lot of stress about how to resolve that conflict. On the other hand, if it's so lightweight and it's toothless... then you're not solving a problem for the marketplace. I think the great thing that has been accomplished in the two years up to the release of those specifications is it was the collaborative effort. All of the engineers from all of the platforms were in a room together having that debate. It's the fear of the certification program that's coming to ensure that they're actually aligning the technology and writing it down and agreeing to it. So I think even though there's been this gap from when the first specifications were out the door, we're still in a place where enormous value has been brought to the market in that collaboration and we're still working on the details on how we'll demonstrate that in a broader context. So there's still time to get involved. These slides are going to be available up on the Linux Foundation website, so I'll post them up just shortly after we finish today. But there's the link for the open container site as well as for the developer communities. And with that, it's time to start to transition to Q&A. And whilst you guys are thinking of your first original question, I'm going to go to Stephen and ask him what was the biggest surprise that he thought he ran into over the last 15, 16 months in this effort we've been underway? And I'm not allowed to use the P word, Emma. Yes you are. No, I'm not. Yes you are. He's talking about POSIX. Yeah, I was part of the Unix Wars back in the 90s and so that's where I got my gray hair from. What I was impressed with is having been through that effort to see the good work that was done in this organization in a short span of time. It was funny because it was a group of really knowledgeable engineers that are used to collaborating in an open source context and they weren't used to building standards and so there was always that tension of they wanted to be moving faster and at the same time the specifications that have come out are very useful specifications and had that right effect in the industry of ensuring that there was a central point of agreement for things going forward as containers become more important for the way people start deploying software. So I think the fact that they were able to, without necessarily going through that whole learning curve of how do you build a standard, to actually come through that learning curve quickly and deliver on these first two specifications I think was enormously helpful. It looks like we have a question over there and while he's getting the mic to mic, I will just say that I think the other thing that we tried to help shepherd the engineers along with on this was that how do you try and structure this in such a way that you don't stifle future innovation, right? I mean, the other thing about this OCI process that was of a concern is that if this locks it down in such a way that it prevents future innovation, that's not a good thing for the industry as well. A question for... Yeah, I saw you were going to certify the runtime processing tools, container runtimes, that kind of stuff, and format, maybe images, but it was more the format, right? But to me, the image format should really be verified at the tooling area as opposed to each image itself. For example, a build tool that builds these images, you might want to make sure that it does build OCI images correctly. Yep. Good feedback. Other questions? And while that question's getting teed up, pull out that smartphone and follow Steve Walley on Twitter. I've kind of been following the standardization process at one remove from the time when I worked at CoreOS. I was in the pro services department, so I wasn't like a developer or anything. I have not read through the spec, but I was wondering, does the spec say things that container runtimes or images must not do, or if it doesn't, is that something that you've ever considered or thought about? Are there things that we should say, no, you should never do this? That's a good point. Mike, you want to... Yep. And that's really important, because the experience that I certainly went through, I got involved in POSIX late, and so when that first spec came out, there was just things that were left unsaid, and there was no flags around that to say, really, we aren't saying anything here. And so it's actually very helpful when you start in a specifications organization that you're able to do that. The marketplace couldn't have allowed it in that situation, because there was just, when you're trying to bring together dozens of products in a marketplace worth billions, sometimes you have to leave things unsaid. Whereas in this situation, because this is still a relatively new space, we were in a good position to actually build up and make the claims, you know, don't do this. Other questions? Well, that one's getting teed up. How many have heard of Container D? You'll want to stay for the next session. My esteemed colleague, Phil Estes, who's a docker captain who works for IBM, is going to be doing a deep dive on Container D in this very room in about 15 minutes. So I'm a software engineer at Epsara. I have looked at the runtime spec for a while, and it only includes what you should specify to run your image, like CPU and other stuff. But it does not describe anything about the API itself, like how the runtime should expose its API, and do you have anything in mind for including API also or is it just going to be just how you specify the... how do you run the image? Yeah, we had a philosophy of kind of crawl, walk, run. And we didn't, you know, collectively companies that were involved in supporting this to varying degrees were worried about over-driving our headlights. So we tried intentionally to start with the very basics, and there are next version topics that I think are getting teed up, and that's certainly one of them, distribution, the other things, right? The other thing that we really are also trying to do with the OCI is think of the, you know, if you think of the Asian yin-yang symbol of black and white and synergy, we're trying to keep the OCI focused on the fundamental container technology. We're not trying to take it, you know, across the line, if you will, into the orchestration space. We're trying to be very complimentary, obviously, to what the CNCF is looking to do with container orchestration. Steven? Yeah, and that question is, it's frustrating for me because that would have made certifications so much easier if we had to add that. And so that exact question has been an active debate for a long time, but at the end of the day, there was also the, the engineers building the spec were in a position that they could actually claim victory at that point, and that was a good thing to do at the two-year mark. So that's why it's still an active discussion. There's proposals underway that will allow us to kind of do that. Have another question over there in the middle. Yeah, have you guys discussed image distribution as far as like, you know, standardizing maybe the registry APIs or something like that, or do you leave it up to the runtime to pull images however it sees fit? Actually, allow me to take this back here. Please. Oh no, you clapped. You clapped and you're one of the engineers helping build the specifications, so I think you should share an answer here. The topic has been like, was just set a second ago up for debate since even before OCI was a thing. And the very first steps were the image, the actual image format, something that could be distributed in the runtime. So now that the V1 is out for the image and the runtime spec, and it's like sabbatical for all the people that were involved for the last two years. Everybody's teeing up what we're going to be working on for 2018. There is an OCI face-to-face tomorrow. So besides like just updates and current events, the two items on that agenda right now are a distribution API and a common way to build OCI images. So it is very, very much demanded and needed because there's plenty of de facto stuff out there but it needs to be ironed down. And thank you, Vincent Bats from Red Hat. Oh, hang on, we'll get you a mic. Damn it, Steve. Steve-o, Steve-o. If you can distribute a content-addressable blob, you can distribute an OCI image. So it's all about figuring out how we distribute those. Like once you have the content IDs, you can distribute it over any medium that can do those content IDs. And figuring out how to do that is the problem. So does that mean we should have a distribution spec? Probably. But also right now it's pretty open in how you can distribute an image because once you get to that ID space, you can be really creative. So these are exactly the kinds of things that we get to debate in this one. And so that's why like the work is they are starting to ramp up again for what the effort will look like for the next phase of specifications in 2018. So if you're interested and your company has a perspective or you want to share your expertise, I would encourage you to participate. See, I mean just a question like that. Steven, if he was a dog, Steven's tail would be wagging because he just likes this stuff. Like the different kind of work. Maybe too strong. We've got time for one or two more questions before we wrap up. And Steven, as we start to wrap up, I'll have you come up here for one last event. But a couple of closing remarks. I have a thing or two you want to make a... No, that was really it. I would encourage you to come and participate if this is something that affects the way you want to start thinking about things at scale. It's not just a game for vendors. There's lots of bleeding edge users out there that have real experience with how they're doing things like deployment today. And so your opinions are valuable. My initial step into the standards world a very long time ago. I was on the user side of the house. I was working for EDS in a General Motors factory and we cared about the standard and thought we'd go find out what it was all about and that was a very fruitful number of years in my career. So from even just an understanding of how specifications happen is always good in this industry. And if you'll indulge us, we have to go on posterior record for this. So if everyone in the audience that enjoyed today's session will raise their hand, say yay! You're all too kind. Thanks for that. Seriously, how many got something out of or enjoyed today's session? Just a quick show of hands. If all of you would take a moment to provide that feedback to the Lynx Foundation, Steven and I would greatly appreciate it. If you found it a little lackluster, well, you've got better things to do with your time than to respond to those surveys. So... Oh, great. Really do appreciate it. Thanks everyone for attending. Do stay for the Container D update following in this breakout session. And with that, a big round of applause for my partner in crime. Thanks very much, folks. Thank you.