 Hi, I'm Mark Velker with VMware and the Deafcore Committee and I'm here today with Chris Hodge who's the OpenStack Foundation's Interoperability Engineer and we're going to talk a little bit today about Deafcore. So Chris, why don't you start off by giving us a little introduction to Deafcore and why the Foundation cares about it. So Deafcore is the board-appointed committee that is defining the interoperability standard for OpenStack and what the interoperability standard is supposed to do is give vendors a guideline of that is backed by tests of you know, a guideline that's backed by tests of the products that they can sell and put the OpenStack logo onto with the intent of giving users a guarantee that they'll be able to port applications written on one OpenStack cloud to another OpenStack cloud. Great, and we should probably specify that what Deafcore is primarily focused on today are capabilities that are exposed to end users. So not necessarily to administrators. The things that end users can actually write code against. Fair enough? Yeah, yeah, I think that'd be fair enough. So Deafcore obviously became kind of the enforcing part of the standard earlier this year and we've got a couple guidelines that are out there now. Can you give us maybe a quick overview of some of the things that people can expect to see in those guidelines now? Yeah, so so right now when you look at the guidelines we are targeting two different sets of what we would call components and these are essentially projects that can be licensed. One is for compute and one is for storage. We're particularly object storage and you know, so with the 2015-05 and 2015-07 guidelines we have a basic set of capabilities that define how your OpenStack compute or how your OpenStack's object storage or the combination which we call OpenStack platform should run. Currently we're working on a new guideline which is expanding the capabilities across those to not only include Nova and Swift as the projects we're testing against but also the rest of the kind of core OpenStack projects including Keystone, Glance and Neutron. So Neutron, while we're talking about Neutron, we should probably talk about some of the new capabilities that are being proposed there. So I think that's one that's been of interest to the community for a long time. So yesterday at the board meeting here in Tokyo the next guidelines draft went up before the board so we could actually start soliciting feedback on that. We'll go up for a final approval until January. So there's a few months here where we have some built-in feedback time. It does include new Neutron capabilities, which I know you and I have worked on quite a bit. So among other things we'll see floating IPs, security groups and L2 and L3 CRUD operations. So you know kind of four buckets of basic capabilities for OpenStack networking for the first time. Hopefully we'll be able to count on. So that brings up the question of how people can supply feedback because not all those things are things they're implemented widely across a lot of clubs today. It's a little bit controversial in some cases. So you want to talk a little bit about how people can bring in feedback? Yeah, so there are a few ways that you can get involved with the Devcore process. The first is just coming to the meetings. We meet every week on Wednesdays at 1500 UTC and it's a great place to you know, you can take a look at the proposed guideline and offer feedback and contribute to the process. The guidelines are stored on the OpenStack GitHub repository. And we also follow the kind of the standard OpenStack development process. So you can offer feedback directly on a guideline through patches and code reviews. Great. So three months until that guideline is up for the board. What do you think is going to be the thing we discuss the most? So definitely networking is going to be at the top of everybody's lists, you know as we try to balance existing network models with network models that we would like to see happen in the future. But I also think that we're also going to be looking at some block and image storage capabilities too and trying to decide, you know exactly what features that we want in there to guarantee interoperability. Okay. So, you know, I think networking is probably on the list as well. Obviously, we spent a good deal of time with that. And the board actually had told us from previous meetings that they wanted that to be one of the big priorities for this next set of guidelines. Because it is something that OpenStack has sort of mutually exclusive options for. So it's kind of a tricky area. But something you said earlier is something I want to go back to. We talked a little bit about how OpenStack is changing as a result of DeafCore. So I think maybe we should talk a little bit about how that's influencing some of the choices that projects are making. Obviously, we've seen a lot of bugs going to OpenStack and into tests as well. And seeing those get fixed has been pretty satisfying as an outcome. But I know we just came from a session earlier today where we had a cross-project meeting talking about things like how to deal with images in OpenStack clouds and how to deal with API transitions in OpenStack clouds. And that's something that we're starting to roll out more of that feedback to the TC, to the PTLs directly, and to the user committee as well. Which is something pretty exciting to see. Any other things that along those lines that you'd like to talk about? Yeah, I mean I think that what you bring up speaks to the intentions of the DeafCore committee and the interoperability process. It's not just a branding and marketing program, but it's a way to give vendors guidance on what they need to provide for their users. It gives users assurance that applications they write can be ported from cloud to cloud. But it also actively solicits feedback from the developers and the vendors and the users to help shape the standard and truly be a community-defined standard. Not anything that is defined by one group. And so in that way, it really captures the essence of open collaborative development. Yeah, that's a good point. So DeafCore as it exists today is really powered by a fairly small set of people that are doing the legwork of things. But we've actually started to see a pretty big expansion in the number of people that get consulted or contribute to reviews and patches going in and those sorts of things. So that's maybe a good note to end on, is talking a little bit about how people can get involved in the active decisions that we're making throughout the course of the next three months, and also for the next guideline as well. Yeah, three great ways to get involved. Come to the meetings, share your voice. Contribute code reviews to the current specs and patch sets we have up for the DeafCore repository. But also if you're running a cloud, downloading the ref stack client and running the tests and submitting your test results is also going to give us great feedback on what capabilities are out there and what we should really be focusing on for the next guidelines. Yeah, I think we've kind of talked earlier about how of the 12 criteria that DeafCore has, about eight of them are trailing indicators of market acceptance for capability. So getting those results in really helps us get some visibility into what folks are actually deploying and what actually works in the clouds that people are operating today. As well as the user survey, we should say that last user survey got a big bump in the number of people that have responded. And that's been really good for us to be able to have a little more feedback from the community. Well, thanks for talking with us today. Have a great summit and we'll see you soon.