 It's it's only fair I was late to the other the panel that I was late to the panel that Monty was Monty and I were sharing so it's only only fitting that Monty will show up in a couple minutes We have two mics we can actually hit out third. Can you guys do a quick mic check? Yeah I got loudest mic naturally, which I don't need at all. So My name is Rob Hirschfeld. I was asked Volunteered perhaps to moderate the interoperability panel Because I have the unfortunate tendency of speaking up about Not the only one of this panel of speaking up about interoperability and its importance and some of the challenges that we face about it so I Managed to pull together some people who have very diverse perspectives on interoperability and experience and so I'm hoping that we can have a lively debate to get everybody ready for beer and cocktails and I have prepared a list of questions. I don't have sufficient devices up here to monitor the Twitter stream but if you have a pressing question come up to the mic and We will wind you in and with that I will remind you keep your answers short Please we have a limited number of mics. So you're gonna have to ask for mics to do it Could you please? We'll start with Troy. Give us a brief introduction Troy Teman, I run the cloud public cloud infrastructure team at Rackspace and also an open-stack board member Hello, I'm Peter Puglian. I'm the individual who works on open-stack at Microsoft. I can't follow that Don't tell yourself short Josh. Joshua McKenzie Co-founder of Piston Cloud opens like board member The unfortunate soul who was supposed to organize this panel and then asked Bob to do it And apparently I'm the the rat bastard who talked to the press about interoff before we were due to do that So this is kind of my fault Jonathan McCourt. I'm the vice president of product and development at dream host where we have a Public cloud based an open-stack in preview called dream compute I'm Bernard Golden. I'm vice president enterprise solutions friend Stratius, and we're a cloud management Company I manage the software company and we certainly know about the issues of interoperability But I have to say I thought when you started off by saying I want you to keep your question your answers I thought you were gonna say clean No, that is not not brief Welcome to drop whatever additional expletives and adjectives are necessary Just remember the And actually if you would and want to tweet about this, please include the hashtag interop and That'll help people track track our back channel if we have one So to get rolling in or we keep saying the word interop Which is sure for interoperability Can you give a two sentence go? I'll start with our two sentence definition of what it means Well The previous panel people were discussing these sorts of interoperability means I have to be able to shift a workload from one Platform to another I'm not as convinced that that is the case, but certainly I think I have to have a sense of Consistency among different providers. So that would be a consistent API level Consistent functionality. I would go so far say that interoperability You know, it's one of those things that a lot of people sort of give lip service to But only is shown in the basis of stuff actually working every interoperability standard I've ever seen is toothless unless you actually have tests that people have to go through and validate against with somebody who certifies it to I already gave you the hall pass That then they're able to certify that something is actually truly interoperable. So that was I was actually an excellent answer I was going to say to me. I agree. It's not so much about necessarily the complete transparency of moving workloads, you know between providers It's more about API consistency not only in Which API's are offered? I think that's actually kind of an important thing because OpenStack is growing really quickly in terms of not just its functionality Also scope additional projects kind of growing up around the edges of the open stack and those are additional API's to support But knowing what those core functionality core API's are and ensuring that they behave consistently across providers And I agree that having some way to measure ourselves is very desirable Being able to know where we stand when it comes to interoperability with other providers So I thought it was interesting you said to I mean what you basically implied was it's a gradient and then you turned around and said It's an API with consistent behavior I figured we could take it out of the technical domain Say if I have a car and I have a hole where gasoline goes in interoperable means if it fits in the hole It doesn't blow up my engine Right, and so that the API is the size of the hole. I mean, I don't know if you have diesel cars Retweet the API is the size of the hole, please I Wanted to start strong right? Yeah, I can get away with this because I'm wearing the mr. Rogers sweater So no one will assume that I had a wicked intent to that phrase from my perspective interoperability is the Area at which we allow vendors to be able to plug into the ecosystem bringing their products to the table, right? So from an open-stack perspective, I shouldn't care which vendor comes in and brings their solution to be part of Implementation but we should have the ability to Create that environment in our case with consistent API's to allow anybody to come in and plug in behind it And that's the area, you know being able to have multiple vendors with different agenda in the same sort of technological space Working together is really the So from our perspective at the API perhaps been covered That's a critical part that that they're consistent and they behave consistently the other two areas that we tend to focus a lot on Our thinking around interoperability is image interchange. So it's not necessarily about live migration of workloads across multiple clouds But I'd like to be able to know that if I have a workbook if I have an image about the capability that that will That I can take that and move that to something maybe not real time But in some way so private public public public that's another piece the third piece Which I think is evolving a little bit further out But we also spend a lot of time with this network interoperability So how do I how do I know that I can connect workloads in different clouds in a way that is somewhat consistent as well So it's it's kind of those three I would say in those in that priority order from Mars our standpoint that Come back the other way and then I'm going to interrupt the chairs I don't think I got to answer that question You're right A brief introduction and then to find in around I don't know about the first one that was a little bit hard My name is Monty Taylor. I work for Hewlett Packard sit on the Foundation board and technical committee and Was around when we started this crazy thing and seemed to still be here, which is a bit crazy and also heavily involved in running the the CI and Obstruct CI infrastructure systems Which is actually where I would come to the the definition of interoperability We right now run all of the project testing across a combination of HP and rack spaces public clouds And it's not so much about moving a workload as it is that we have defined the workload Consistently across that as if those two clouds were one cloud And so what I would like to see is all of these various different open stacks behave sort of like the internet or the web In that rather than thinking about all of the different web servers And how those might interoperate with each other that the web itself seems as if it is one large thing And I would love to get to the point where we have Just an open stack cloud that HP provides endpoints for and rack space provides endpoints for and aptera and dream host and Even of aunts and everybody else and then there's private ones because you have private web servers And you have private internet connected things in your home or whatever and so that might be a little bit nebulous, but That's that's that's my perfect happy unicorn rainbow Yeah, words like nebulous and canonical which have very good technical meanings I've been have been sort of captured We have no words left to use in the cloud ecosystem that are not overloaded Like cloud or so passing passing the try if you would I'll give you lead on this one Some of the reason for this panel is because we are using we're throwing around interop as a Statement as a bad thing as a claim We sort of get in trouble talking about interop right there was an article recently that gave rise to this panel Talking about how HP and rack spaces clouds did not interoperate So can we actually make statements like that? Are they fair statements is it reasonable and then for you and then everybody else? Yes, the simple answer questions. I think we can make those statements. I mean I don't I don't think they are interoperable I think there's a lot of reasons For that in our particular case We were trying to actually get a product to market We had to lock down with what that was going to look like while open stack was still moving We locked it down. We got a product to market We proved that it worked at a point where everybody was saying we didn't know if the stack worked and we felt good about that But then it was it's got to work like everybody else's which is a fair expectation I highlighted this a little bit at the keynote. I did the last summit I did a blog post on where I think we've got gaps that we need to work on to keep going So we we definitely see it. We want to work on it. I think one of the things that's missing There was actually in the in the infamous article that Josh was quoted in he referenced the fact that by the defined interoperability Standards were not compliant with open stack and I think actually that implies there's a well-defined inner That's what it was quoted. It is as always written. So there was nuance. Okay Everyone in the ecosystem is in compliance with those defined standards because they are incredibly broad They basically say you have to run over and you have to run swift. Yes, and that is it right at my point It was gonna be I think the missing point is we haven't actually defined It's left up to every individual implementer of open stack to make their determination about interoperable and what looks right And you know part of it is I made a guess the guys at HP made a guess Pistons made a guess and some people have guessed more alike than others But you know, I think I think this is a big problem for us to actually define what it means so that we're all working Can I respond to that so the original effort to solve this we kicked off two years ago if you recall this was Copying what Simon Crosby had done with Zen server and we started fits the faithful implementation test suite and We ran smack into the central issue of interop which we still have not solved and in the latest Resurrection of fits which is now the ref stack interop project that Monty and Rob have been working on We're ignoring that problem right now So that we can get something done Everybody in in this panel basically said interop is about the API Which is the assumption we are taking with ref stack is we are going to test the API of every product and service and Then use the results of that API scorecard to say how interoperable because it is a great name Which I think Bernard pointed out What we're saying is the API matters and what code you're running under that API does not and that is the Two paths to interrupt that we have never been able to get to a consensus on there was a first meeting We ever had for fits was that debate we ran into the wall and we abandoned that until we had a foundation to enforce it Yeah, I think you know we are at a point. Hopefully we're gonna move forward on that. I actually have that as a standalone question Yeah, I know from a from a cloud to cloud is theoperability standpoint, you know We have to obviously in some cases deployment choices might Interoperability right or portability whatever it is that you're Looking to achieve in terms of interoperability So, you know the I guess a broad definition is obviously necessary because obviously, you know from my standpoint in a situation Where I'm using windows as my hypervisor, right? I'm obviously have a completely different and operational environment that I have here Just to get that deployment out there now Obviously, you know from a project perspective try to stay as close to everybody else To keep it that pain equal but in reality when you go to deploy that we have fundamentally different challenges when deploying windows Versus deploying linux. So those are things that you know, we obviously You're not gonna, you know, we're not talking about API's but yet at the same time It where we may break portability and we may break other things because of just the way that we deploy The components that are involved Yeah, that's actually really interesting. I think something both of you said, you know kind of made me think seriously It's it's not just the API. It is the underlying implementation sometimes And you know you see that in open-stack networking. I got to get used to that And you know, we're directly engaged in that One of our one of our guys is actually the ptl for that project and he's constantly engaging with a lot of different vendors we have a lot of different limitations of these general concepts and There's a lot of hash out that goes on in the community just ensuring that these things work together such that I can pick a different vendor for a particular feature and Have things work for my customers in a very similar or very much the same way So sometimes it hashes out inside, you know open-stack community in the open-stack project itself other times it doesn't so another Interesting thing about us as we run stuff, you know, that's something that's different and so we do have Swift But we're not using Swift. We're using Seth to implement Swift And so what does that say about us in our interoperability? Well, we're committed to that API. We think it's important, you know And so I think there's a lot of different ways to skin that cat and it's just the important thing to note is it is those API's The things underneath do matter. So I don't know. It's kind of happens inside the community and outside I guess I'm not really sure that I have something to add to that. So I'll just I'll just pass the conversation on all right, so so I think actually The thing that makes me think when we talk about interoperability and we talk about The things you guys have been bringing up like is it the code? Is it the API? I'm of the opinion that I want people to run the code, right? And I'll also put a pin in the Swift stuff thing because I think that's a I think that's an outlier Due to code structure that doesn't work the way the rest of the projects do Based on the quantum Cinder Nova Glantz model One would imagine there would be a self plug-in But that's a different conversation and it's it's one that that also can be had for long amounts of time. So Yeah, we know that for a brief second the reason that we want interoperability, right? Is not just because we all like each other and we think that we that we want to have a happy party There's a there's a real there's a real business benefits to that, right? The the the business benefit is that is that we're able to grow the market and we're able to do things together that that none of us are able to do Individually it's just not possible And and so when we so the reason that it's important to me when we talk about interoperability that we're actually aligning more and more on on code and not just on on API's is that working together is is how like the business goal of working together and Winning and growing the market in that way also involves the community being all of us and not the community being something that each of us Interact with but that that comprises the set of us And we really only do that when we when we jump into the to the code projects themselves And so just API's then everybody goes off and rewrites their own version of it in Java or whatever Ruby or whatever thing They happen to like and then we're no better than we were three years ago To your point you're exactly right if someone goes and implements it in Java and someone goes and implements it in another another Software language then you know that that's where you're opening yourself up for breaking into a problem interoperability, right? If we do work along that common code base it only strengthens the project as a whole So I actually was gonna put you back on the spot because I if you didn't add I had a question question for you Do you have a comment? Well, just I mean in my initial comments I assumed that everyone's gonna use the same code and I think sort of you know, here's this interface, but we'll go implement it differently Just doesn't really isn't really helpful I think the bigger challenge is how to make sure that people are kind of grabbing the same sets of code so you know from a from a customer perspective if somebody says we have grizzly you kind of want to know Oh, it's this sets of stuff not well, we grab this stuff and we grab something completely different But we're both gonna label it grizzly because from a user perspective or a vendor perspective. That's a nightmare I'll I'll say I sat in on the API thing Yesterday, I was a little concerned that I heard somebody say well Why don't we just continue constantly evolving the API and never really defining it as a certain level From a development perspective, I can see where that's attractive, but from a user perspective that would be disastrous So you said two different things the first one being, you know, how do I know what grizzly actually is? and you know one of the challenges open stack has is that Because it is really an umbrella across every possible cloud you might want to build We have an enormous number of configuration options. I think it's what more than 600 options now And so we we have proposed this project called ref stack specifically to say this is this is an open stack That is going to define interop It is not any vendor's flavor of open stack, although all of us would love it to be our product We're specifically making it not that and trying to get to what is the what is the middle bar that the ecosystem? I either you know the instratius is I can't say this too many vowels in that now In strata says What what API serves the needs of the folks who consume the API as opposed to serves our whims as developers? So for not I was going to put you on spot because you have a unique perspective here because Your company supports multiple clouds and then so interoperability for you to call the whole new dimension Be by being able to work translation translate workloads not just between open stack clouds, but between other vendors clouds, right? That's true that we And sort of the way we've done it I think it's a kind of interesting architectural perspective which is we've created an open source product called design which any of anybody can use and Basically, we use that encapsulate these differences. We've created kind of a I would call it a taxonomy of functionality across different kinds of Stuff like you know launching virtual machines or doing this or that or whatever it might be so that way we can sort of gracefully expose the functionality of the of particular cloud providers if you sort of Serve up a soft pitch on this API stuff because one of the challenges We also face is people who implement the API faithfully, but then don't execute on it very you know, so we I won't name any names and actually wouldn't be anybody at this This conference, but we've run into vendors who have an API that as soon as we start using it start throttling it because they say Oh you you are actually a denial of service attack So You there's faith There's the syntax of the API I would say and then there's the semantics or the function the operations around and both those are really Critical for and not just us. I'm not just sort of saying oh it's us. Just think of us as being you know users Us representing users who want to be able to use all these clouds There was a What so there's I have two questions in Cuba. We're gonna do yours first I Want to come back and talk about money. I think that's a really valid point I do want to talk more about applications for a safe. Yeah, we're halfway through I was gonna ask you guys to scramble your order just to make this a little bit more interesting interoperate your chairs, please This is gonna be like musical chairs where somebody's gonna sit down only this is the only this is the only restructuring of the I Big win is I got the mic from Josh and I've ended up the same chair Go ahead, please Okay, so I'm Chris first my BM and I have that problem in spades And I'm trying to the same co-base But really what it blows down to and I think that Monty mentioned it earlier is you know, the web just sort of works and it works across Every no matter what website you go to it just works. There's a reason for that It was written down in like 1991 and It hadn't changed a whole lot Right. We all agreed. This is what HDP is and we're working within those parameters We aren't going off and reinventing the wheel every week. It just works HTML took a little while more to sort of sort itself out, but eventually the vendors Worked it out and agreed. This is what it is Now we're working on five. I know five Won't go beyond that but I guess my point is this and and and Bernie mentioned this as well. We keep thinking we can keep Changing the API from one release to the next we keep thinking we can add all kinds of cool new stuff up And then expose all kinds of extensions, but that's not getting interoperability You may have SPI plugability, but you're not getting interoperability above if everybody's doing different things down below So this is a pretty simple thing compared to the entire Set of API's that is required to run a cloud private or public and also and you all of those So hold on a second, I'd like to address you directly I think the wrong you have to look at this like Okay, HTTP is like a vendor coming in and adding more functionality to the layer that we built To make interoperable right like IP allows us to all communicate It allows us to have this web It allows us to connect these devices from any defender any different vendor and gives us an entire ecosystem that allows Us to build other technologies on top. That's essentially the same thing that open stack is right is a Framework that allows us to add on to and build on top of like So from an ACP perspective that I look at that as well That's just additional functionality that we built on top of that base layer that raw fundamental layer that we all agreed on From strictly communications in terms of IP but in terms of the cloud We have a lot more things that you have to be thinking right because you know You've got different vendors bringing different things someone mentioned something about you know making a particular Vendor choice because of particular functionality that may that that device or component may add to your cloud and Once again if we all stay true to that fundamental underlying layer no matter how I implement it You know you name it it's a we still have a commonality that allows us that tier of so I think one of the underlying pieces that you described is that at some point The industry came together and decided that making this stuff work together was worth sacrificing developer flexibility and vendor Agendas in the sense of the greater good right and money talked about this a little bit earlier and I think even Josh alluded to it at At some point the open stack community either by someone's here from the market or just within ourselves We're gonna have to decide that a certain amount of that innovation of flexibility and then a certain amount of our independent company priorities need to run second or third to Interoperability for our users and the problem is we haven't done that yet I mean I think we're we're as close at this conference with some of the things we're talking about some of the noise that we're hearing To move there, but I don't think we've been there and ultimately, you know We have to decide that being interoperable is more important than what? You know a product person at rack space or a customer at rack space or something is streaming for or that some developer Insist he has to have to be able to do the coolest thing in the cloud and those are hard decisions to make I Think we've all struggled with them in different ways, but I think if we don't figure that out Then we're just gonna lose that opportunity So I think this if I could do a poll quick poll show of hands How many of you on your laptop have adobe flash? basically everybody What happens when a standard gets baked too early? And crushes innovation is that the innovation leaves a standard and it happens somewhere else so the innovation of the web since What 2001 to 2000 when did we start on five? Happened in proprietary plug-ins happened in active X for a while, which was painful no offense to Microsoft It happened in flash and have it etc So the the other the other point and I see Todd in the room and Todd's gonna disagree with me on this one This is not me as a board member. This is me as a co-founder of open stack We started open stack around a philosophy of rough consensus and working code We swore this would never be a standards effort There were already standards Efforts I was on them for cloud computing and they were a giant waste of time So when when we are clear on the definition of cloud and we are clear on the definition of workload The next person who says workload in here as if it's a real term is going to get smacked in the head Maybe we should just call it load load Then we can start you know the retroactive application Actually, I quoted this in my keynote at the first open stack summit the first keynote of the first summit in Austin I quoted the fact that the RFC process After the fact standards based on working agreement and interoperability that had been built Amongst peers in small collaborative sessions was the spirit of open stack and we'll continue to be the spirit of our interop efforts The things that we have already decided work well enough to call done. We will standardize on and then we will enforce Everybody keep that between yourselves. Yeah, there should be much less agreement and much more bickering I think is what we need. No, I was gonna I mean similar to that. I think you're exactly right the of course the the sort of My negative example of where where a standard sort of stuff doesn't doesn't work out in the way that we want it to work out is is POSIX right which was a Bunch of a bunch of unixes that had gone off into the weeds and they made POSIX and nobody cares because what it wound up being is then it got locked into The standards body and you had it you had a least common denominator crappy interface That then couldn't move and so then as as things came along You know the the GNU utilities came along which were fantastic and extended POSIX Because they didn't care because they wanted things to work and then Solaris decided to ship this the GNU user space as part of Solaris You know Linux did the same thing Etc and so then you had the working de facto standard which was GNU and still is and you had the and then you had the POSIX definition I don't know if anybody's looked at POSIX tar But it doesn't work and and so I think that that while While standard is why I'm a huge fan of interoperability and I think that we need that I think that it's really important that that that emanate from Things that work and that solve our problems not that are Theoretical solutions to theoretical problems or things that are designed to Rook consensus just enough so that we can say that we're having consensus But none of us actually have to give in a minute that never happens doesn't That never happens. No, never. No, but I just put a clarification what prioritizing Interoperability was not meant to be an endorsement for standards because that totally agree. That's a terrible way to go because I was gonna You do have to make some sacrifices for interoperability. Yes But I also I want to disagree a little bit with the point that we we have to prioritize that I think maybe that's not what you're saying. We don't have to always prioritize that above, right? I think we're gonna need these this innovation around the edges on new API's and new features and even extensions I mean, there's a reason that there is an ability to extend out the open-stack networking API because it's it's a mason project And we have features we need and we want to deliver our customers that weren't there So we built them in extensions and when those features are available in open-stack networking We'll put in a shim and we'll move to the standard We'll move to the community consensus API, but I think the critical thing is it's okay to innovate It's okay to do different things, but when the community comes to consensus, let's all gather around it and adopt it That's that's the key thing is We're doing the extensions. We're doing the innovation We're allowing some of those to be de facto standards like in Nova There's a whole set of things that are not part of the Nova API that are quote-a-quote extensions that everybody thinks you're missing If you don't have them and so we do have to get better I think declaring that standard as it's moving because it will move rapidly But we need to be able to say look if you're if you're gonna get the Nova API You're gonna get the set of things and it's and it needs to move more quickly than I think it has In a stated way a lot of us that work in this get it know that if you don't have key pairs You're not you're not Nova, but nobody outside this programming knows that they should expect that right we're gonna get better So there's actually a pair of things that that are solved by the user committee, right? One is us knowing which API's are actually being used in other words the development community hearing from Stracious that You know we expect in our taxonomy for the key pairs Interface to be supported in every opens that cloud we expect floating IPs to always be there So that's that's how we hear which ones are important It's also how we hear which ones need to be frozen You know at the point and it's it's funny that the unstructured version of the user committee at this point Is George Reese on Twitter, which is why we are trying to structure this slightly But that is the the primary source of feedback we get for the OpenStack API's Is is George Reese's opinion of our lack of XML support and frankly we didn't write XML support because we didn't use it Didn't think anybody else did But turns out we were wrong To piggyback on The I'm just gonna stop prefacing what I'm gonna say and just say it rather than talking about saying it Is basically that I agree that we've got it. We've got to do edge Edge innovation and we've got to be able to push those things forward the the one thing that Along that that I think is really important is that we try We try our best to we it's really hard sometimes to try and do that in the context of The community effort rather than over to the actual side Right because when it's over to the actual side Then what happens is you start going down the path and then the community just comes right along and does the other thing and then Now it's a competing thing right now It's now it's somebody with bad blood is now unhappy with some other person and now you've got you know three different versions of the load balancer as a service and We don't need that it's not useful to anybody. We've got multiple different DNS I mean like can that's not necessary and And and if we if we do that we've got enough space to do that innovation In there and we don't we got to figure it out right because because if if there isn't the space for that innovation to occur On the edges, but within the confines then we're doing something wrong I'm gonna we have five minutes left to go I'm gonna ask you to hold to hold your questions. That's right because I want to do speak questions so we can do two or three questions one sentence answers What's the need you guys one sentence? So how do we make interop pursuing interop profitable for the people to work on companies to work on? not Not interop is not profitable interop is already profitable It's gonna say we we already have by the momentum we built on open-stack we just need to follow through on the promise I Say it's it's pretty easy. You'll start getting a lot of friction from customers who will say I'm not ready to adopt because and then Vendors are very good at responding to dollar signs for customers. We don't have a choice That's the answer. Yeah, I was gonna say So the next question is test is one of the things we identified as a critical component for interop How do you make test sexy and encourage investment in tests? Todd promised this a bunch of IBM guys, so They like doing it. They have a very strange idea of sexy I thought I thought the open-stack CI team was already sexy I Think it's more about fun And I mean there are people that find the stuff incredibly compelling and it's about getting them and giving permission to go work on it Right, I mean that's you find people like Monty's team. We've certainly built up a Group of those folks at Rackspace that are trying to get more engaged in that and I think the more we find those people and give Them permission to go do it It'll happen. It's already happening. There's a lot of momentum around this so There's one more is is Acknowledgment right we remove roadblocks the biggest roadblock right now is that open-stack CI doesn't get counted So which we brought up yesterday There's most of where our work and Monty's work on open-stack happens is not counted as source code contribution Because we're not in the biturgy of stats. Thank you. So those developers don't feel like they're recognized They don't get counted. So it's not it may get sexy by making it This this came up in our previous panel talking about technical meritocracy and people being excluded from it Because they were code developers in court So two more questions. Oh So we want interop we want to be able to claim interop How do we get to a point where somebody can speak have a certified and do we need and how can you claim a certified interoperable open-stack cloud Ref stack work. So the goal the the the skunkworks project, which is not officially a thing because Monty and I Vendors of products and services can register an endpoint and Schedule a scan of their product or service and they'll get a scorecard these API's you support according to the open-stack standard according to this version or not with these caveats they can then take that scorecard and present it to customers and also at some undefined point the future perhaps The board could use that to regulate the use of the trademark because today's policy is Nova and Swift equals the word open-stack We can maybe get a little more granular We we actually and as a follow-up to that we we've solved all of the technical problems around that two hours ago in a session And if you'd like to be the ether pad, it's either pad at open-stack.org slash Havana dash Snatch testing I Don't believe I remembered that when I think it's solving it the way we've solved every other, you know, it is about code Right, we're gonna write tests that are not a big and you know, everybody's gonna have open So everybody's gonna know what to expect because they're gonna know what those tests look like And you know, I think we solve this the same way we solved every other problem and open-stack And I think we've got great ideas. I mean, I think that was the most exciting event in any board meeting was when I Think all four of us were there and go this is the way we need to do this And and if anybody here wants to get involved with that there's a huge opportunity because there's a lot of work to actually make ref stack the idea ref stack the reality and You know anybody that wants to jump on that one absolutely join us. It's a sexy thing to do So so that was sort of what I said in my initial remarks Which is there has to be some sort of a certification test that you have to see that every Every standard that's ever done that that's ever been adopted has a certification test They go through it. They get a score and you pass you fail and then the marketplace starts demanding that and you know My speculation is once that thing is defined and it's available Once one large vendor sort of signs up and does that everyone else is gonna fall into place because they're they're all gonna find out Oh, those people are choosing that large vendor because that person could say I'm certified. Oh, I better have that too From a Microsoft perspective, you know, any OS vendor You always have things like hardware certification validation, you know, once again from an open-stack perspective it obviously makes sense Can I ask the panel a question or in the audience as long as I get time for my last question You get time for the closing one So the question is we talked about this idea that some APIs or interfaces should be frozen And we talked about some actually are still evolving We have to talk about this idea that some interop is based on just API's and some has to be based on learning the same code And a lot of that is about capturing this community dynamic Is it possible that it's as simple as saying When an API is frozen because we've actually Innovated to the point of a standard the implementation stops mattering as much and we could just say, you know, match the API I I would agree with that actually I believe that that's the point where Where it's less once that once once we've evolved it to the point where it's it's a thing like it's it's a it's a Memcache D is actually a really good example of this, right? Memcache D. It's actually a reasonably simple thing It turns out it's a little bit harder to do it properly But it's it's an understandable thing It got to the point where it was it was It was solid they made a tool called mem capable Which you can run against a memcache D server to make sure that it works And and they did this around the time that it had become such a normal thing that people were just Writing an M.M.Cache D API in front of some service that they'd built this is now like eight implementations of memcache D But that didn't at that point take away from the growth of memcache D itself, right? Memcache D itself had won because why the hell would you run anything else other than memcache D for that purpose, right? And and so that actually proved that it had that it won the space rather than do the other thing, right? So I would I would be right in with that If you guys want thumbs up on that I think we've got agreement on that let's there's right I think this is important. We have a tendency to see things as very black and white and The nuanced answer here is that over time The definition and the need is going to change and I think that sums up a lot of what our discussion was about My last question was shifting gears a little bit is you're gonna go home You're gonna talk to your significant others your parents your pets whatever it is you want to talk to and you're gonna say I was on an interop panel What are they gonna think you meant? So I I'm just moving into a place in the village in in New York So I'm I'm fairly certain that they're gonna think something involving a wig or Or some article of clothing. I don't normally wear or possibly operations related to such things Might might be what this was about, which I don't think is what we've talked about so far The being strapped to a board or waiting surgery So you you know me well enough to know this answer I have no friends outside of open stacks, so they will all know Exactly what I was talking about Very few inside What should be my neighbor Well what I can say is I've given up on having those conversations with anybody in my family They just go yeah. Yeah. Yeah. Now. Let's talk about something important So I probably won't have that but I I definitely will be saying that These things are very kind of responses. I get at home. I definitely I definitely am going to pass on to George Reese That he is the de facto Test harness for the open-sack API. Reese is a service. It's great You should you should see what he puts on to the internal Watercooler Skype chat that we have the stuff that goes on Skype is around Twitter is the censored version There's gonna say mine's gonna be a little bit like Bernard's cuz So I'm about ready to go on a three month sabbatical my wife my wife's reactions We thank God you're going as better. So don't have to hear this again. So that's about all here Everybody. Thank you for participating panelists. I think they did a great job