 Test, test, test, test. Good deal. Hello, hello, hello. Welcome to the Stack and Beyond Analysis Paralysis. My name is Nikki Acosta. I'm the co-host of OSPod. Used to be called OpenStackPod, but apparently that is a trademark violation. I also am a cloud evangelist. Now at Cisco. And I'm really excited about my panel today. Since we submitted, we've had a couple of find and replace options, but great group of folks, do you want to introduce yourselves? Sure. My name's Jeremiah Duly. I'm one of the principal architects at SolidFire, one of the sponsoring Cinder storage providers here. And I believe this is my seventh OpenStack conference. So it's fun to see the progression from year to year. Perfect. Hi, my name is Shamal Tahir. I'm with IBM. I work on IBM product cloud as an offering manager. And within the community, I'm really involved with the product working group, the enterprise working group, as well as a newly launched initiative called SuperUserTV to get operators in front of the OpenStack community in a broader sense from video perspective. Hello everyone, my name is Andre Bearfield. I work with BlueBox recently acquired by IBM. So Shamal and I are recently became teammates, which was not the case when I think that this talk was submitted. But I work on the product side from the instantiation to the acquisition of the BlueBox cloud, private cloud as a service product. Thank you, my panelists, you guys are awesome. Good looking panel too, so diverse. Shamal, you are part of the product working group and I saw the email that went out this morning or yesterday morning about the product roadmap. Can you tell the folks in the room what the product working group is and what your group is working on? Yeah, absolutely. I think it's very romantic this topic actually is so the product working group is a community working group where what we're doing is we're working with the user committee and the user committee is defined by end users and operators, so Subbu from PayPal is the chair. We have John Perlow from MIT and we just got Sheila Sabi from Comcast who's in the user committee as well. So we work on the user committee's behalf. Within the user committee we have different groups that represent different market interests, so enterprise users, telco users, HPC users and what the product working group is doing is taking requirements in the form of user storage from all those different working groups that represent different markets and voices of customers and getting them into a format where we can turn them into actionable specs, blueprints and share them with the project teams and generally what we're trying to do is we're trying to deliver things that are cross-project, multi-release the big rocks if you will so rolling upgrades was one that we're chasing right now. We're looking at life cycle management as another one so really focus on getting the voice of the customers and operators and open-stack consumers back into the development processes, the bigger focus of what the product working group does. We are also generating a multi-release roadmap view so what we're doing is as we're communicating and working with the PCLs, we're asking them what are you working on this release? Cool, what are you working on the next release? Okay, we're pushing the boundaries but what are you working on the next release? So we'll ask them about 18 months worth of where are you going? And that data is available in the roadmap format on openstack.org now but the cool thing is as you're planning for different technologies as an operator you can see where open-stack is going and be able to plan a little bit better hopefully. So are folks like, do they not like you guys? Cause you're, and gals cause you're driving these requirements or are they pretty? So driving is a bad word, we don't use it. So but yeah, so in the beginning there was some tension especially because yeah it was a concept where people were thinking that okay as product managers we're gonna say oh this is what you need to do and go do it without any resourcing, we're just gonna throw the requirements if you will over the fence. And we were very clear and we've been around for a year now, we've been engaging like every month with PTLs, the technical committee, cross-project teams just to ensure that if we turn user stories into requirements that we're gonna bring back into the community from a development perspective, we will make sure that we have development resources that are willing to work as SMEs on those deliverables as well. So it's not just requirements, it's actually requirements but then a lot of the product working group people are companies like Cisco, IBM, HP, et cetera and we're saying that we have development resources that we're willing to align with these user stories that are coming in as well. As far as the project navigator which was announced yesterday where it shows the maturity of all the various projects the adoption rates, all that good stuff is that something that that group is also working on? So actually that's interesting so we weren't working on originally originally it's actually the project navigators related more to the tags works there's two types of tags, there's a TC oriented tags and there's operator tags. So as OpenStack users people wanna know, okay what percentage of this project Nova how many people have adopted this project in production? And that data is really useful to figure out like how mature a service is. So originally that was a purpose but as we're building roadmap use of projects we're actually in conversation with the project navigator team now to take the roadmap data we're building and make that visible through project navigator. So and maybe this is a question for all of you what are some of the requests that are coming down now that we've sort of reached critical mass and sort of OpenStack has won the open source cloud war if you will what are some of the requirements that you're hearing from users? How are they managing through all of the different vendor options versus open source options versus what they're trying to roll on their own? Like what are the challenges there? There are a thousand times a thousand million times a million there's so many options I think that one of the greatest challenges is that there are new technologies being developed always and so there are always new options and new ways to approach how infrastructure is being deployed how infrastructure life cycles are being managed the interaction between storage and compute and what sort of back ends can be used and how just different ways to abstract away the physical machines from what's being consumed by the user and I think that is really challenging to build a product that's compelling in a market where everything that lives just above this product is in constant state of change. Yeah well and it's almost like we've gone backwards right I mean when we look at OpenStack three years ago it was a disaster to install it was trying to figure out how to get from I want this to I can provision capacity was such a immense undertaking we spent all this time and all of these resources to simplify that process right whether that was the consolidation of the distributions whether that was just making the product itself better whether that was pouring resources into the things that we knew customers were using all of this stuff went into making OpenStack usable installable make it something that could win where we needed it to win from an application standpoint but then once we finally almost mostly got to the point where that was the case then we took the other side of the equal sign which was the actual projects themselves and just blew it wide open so everything that we learned we're now trying to do at a scale that the tools we use to make the core of OpenStack better at least in my opinion don't look like they're taking a whole lot of hold or have a whole lot of chance when we start increasing the number of projects and there's the natural issue of competing projects and which of these when we need a navigator when we have to have a dashboard to show us which of these projects do what and how long and by who it's as much a sign of the issue as it is trying to solve the problem so it's not just like the more telemetry we have the better the more telemetry we have about the projects and where they're going and what their relative maturity is none of that is a bad thing but the amount of effort that it's going to take to keep up with that in order to maintain this simplicity that we worked so long to get to from an OpenStack deployment standpoint I think it still remains to be seen whether that's even a viable path to go down. So what happens at that point? Does the market find winners and then acquisitions happen and the losers become losers and they go away or at what point is OpenStack too big for any one company even? At what point does it become too overwhelming to be considered as a viable option for adoption? See and I think that this is what Jeremiah said and what you're asking right now are the things that lead to the analysis process because at the end of the day OpenStack has services and we're adding more services but then we have things like DockerSorm, we have Mesos, we have Kubernetes, we have Cloud Foundry, do we integrate with those ecosystems or do we need to provide those services ourselves? Like basically what's OpenStack's role in the bigger layer cake of the data center if you will? And I think that is something we need to really have a vision and definition around to be able to then say, okay, enhancing this and adding projects here is cool. Adding things here, yeah maybe we're inventing things that we don't need to invent. Right, one of the things that I've heard folks say in terms of the scope and size, especially on the user end is that networking continues to be a challenge. Why do you think that is? It's the hardest part I think. I think the way computers communicate and then virtual resources communicate and then trying to manage that in an automatable way is just the most complex piece. But one of the things we learned even just yesterday is that Neutron has more commits in this cycle than it has in the history of the existence of OpenStack. So I think that- And I think of all the silos, right? We spent the last 20 years breaking everything out into silos. I think nowhere does that show more than in the complete failure of getting networking on board the same way we've gotten everything else on board. Right, and some of that is that it's hard and some of that is that from a data center standpoint so many of us who come from an infrastructure background we just abdicated all of the networking out and as long as I could get from point A to point B, good job, I'm gonna keep doing the things that I wanna do. And I think that it's only been the last couple of years where we've realized if we actually want to integrate that from top to bottom, the networking teams and the networking experience needs to be something that's a full fledged member at the table and I don't know that it'll stay, I don't know that it'll stay kind of the rear echelon forever, right? I mean we know how to make that work, it's just a matter of getting it into a user consumable format but I think that the state of software defined networking in general is one of the biggest indictments of the siloing of IT technologies kind of in general. So two points I wanna make on networking as well are one, it's interesting because in Colin Mestri's keynote he kind of showed that okay and Jonathan and everyone's kind of has been telling this message of one platform for VMs, containers and bare metal. And then when Colin said oh and by the way networking crosses all of those. So A, it's such a integral part of any, whether using VMs or bare metal or containers, that it's always top of mind. So it's almost like at one point Honda was the most stolen car in the world. And it wasn't because people wanted Honda, it was there are so many of them that they just became by involving the most stolen. I think networking is one of those things that it's so needed and it's such a necessity that if there's issues in that layer they surfaced really fast because everyone's using it. One of the things that kind of struck me and I've heard this a few times in the last few months from Jonathan Bryce was that he's referring to OpenStack not as an open source cloud software platform, it's an integration engine. Do you agree that that's what OpenStack should be? How far up the stack should we say okay here's where OpenStack's gonna live and the rest is what it is? I don't think there's any choice anymore. I mean I think that when you've introduced so many variables, I mean when you've got millions upon millions of different pieces that you could plug in there. The hard part is not the individual pieces, it's the integration, right? It's easy to make a Lego. It is hard to build something that you thought about using the Legos that you have in front of you. The integration becomes the only part of that that is useful, particularly when there are so many people working on so many projects that we can pick and choose the pieces that we want out of there but putting all of them together, the only thing that sits in the middle of that is the OpenStack foundation, right? I mean it's the only glue that sits in the middle there and at some point all the rest of it just becomes window dressing, right? It becomes a navigator to see who's working on what and where in the marketplace can I go to get which piece to put it together but how all of those work together and get patched and upgraded and how they work with different networking technologies, that level of integration, I don't know that that can be optional. Yeah, I think it's very apt. I think that kind of what we're talking about here are all these options, all these different ways to do things. I think that if you think about the technology that we're building, we're developing with OpenStack and expecting that at some point it's gonna settle in to a done state, it's absolutely ridiculous. I mean what we're seeing is all these pioneers having more ability to build infrastructure and build their ideas. OpenStack enables that sort of fertile land and I think that where we actually have to settle in is knowing that all these things will continue to change and new technology will continue to flourish. Which makes it really hard to manage a product based on OpenStack. Absolutely. But what will happen, what will happen is that that work of deciding who wins, that work of deciding how things integrate will move to the next level up the stack which is the system integrators. And from a solid fire standpoint, what we brought to the table was the most programmatic storage platform that we possibly could that did everything Cinder could out of a block storage platform. And so when we talk to integrators, what they're doing is they're deciding on behalf of their customers. And when we work with Morantis or when we work with Cisco or we work with IBM or any of these other groups, what we see happening is that there's somebody internally who's building one of these products that then gets sold to customers who's saying, you're going to get A, B, purple, blue and green. And I'm going to put those together and that's gonna be the product that you get. And now there's a middleman between kind of the fertile ground on one hand and what vegetables are we taking home in the middle? Which is both good and bad, right? I mean, it's good because it makes it far more consumable for the end user. It's bad because there are probably seven different options that they could have used that may have been better, that may have worked more, that are being decided largely by the bias of whoever is managing that product inside the systems integrator. So to be real about it, the end user is still gonna get what the end user gets. The question is, is that something that they're going to get that's pure OpenStack or is that something they're going to get as a pre-packaged appliance from Cisco or as a pre-packaged solution from Morantis? And I don't know that it's a bad thing. It's OpenStack, it works, it solves the need that the customer has, but all of that fertile ground for innovation, I think it becomes a lot harder to convince people to start pushing into there when what you actually need to do is figure out a way to get IBM to support that product or project or Cisco to support that project. Which seems so contrary to the premise on which OpenStack was built. It was like choice, the vendor lock-in, but ultimately is it all going back to the vendors at this point? Well, somebody's gotta make money, right? I mean, somebody has to put this together and then make money off of delivering it to customers who use it to support workloads, right? I guess I kind of disagree with you. I think it goes down, it will always land in the hands of the users. And I think that the user will always demand the system integrator, the big businesses that are paying or putting their resources to these projects will demand that we line up in an area where we can support what they want to do. I think Docker is, I hate, this is not a container talk, but I think that's a great example of where users and really treating the developer as the first class citizen and the person who will ultimately need to consume the technology and watching the way that changes the direction of an entire community of people and how we approach the way we build cloud technology. Then let's meet in the middle. Let's say some users, right? Because there are obviously many strata of OpenStack consumers and they're always going to be the guys who stand on stage at a keynote who are very much vested in both an ecosystem and a set of functionality that they have to have and they're always going to be, they're gonna be voting with developer bodies and with alignment to vendors. But the 80% of the customers who are going to be consuming OpenStack, I mean, they wouldn't know what to do with the navigator. Right, I mean, they have workloads and they have an internal operational process and they wanna be able to support those workloads. And OpenStack is the way that they have chosen to do that or the platform that best does that for them. And I don't think the vast majority of those consumers are going to have the time or the inclination to invest that much into what the direction is and where it's going. They have, you know, there's five things I need out of this platform, go. And who's not hiring? I mean, everyone's desperately short on talent at this point, right? How many product folks do we have in the room? Raise your hand. Just a few. How many times does someone come to you and say, hey, I want your flavor of OpenStack, but I need you to support this into your legacy storage or, you know. Every single time you talk to a customer. And what do you do? Like as a product manager, what do you say to that? Like, do you tell, you know, I see this like continual struggle between product and sales where sales is like, hey, in order for me to close this deal, I need you to support this sender driver for this particular storage option, Pure Nimble, you know, whatever it is. And on the other hand, if you spent all your time certifying all the possible sender drivers that were out there. All 70 of them. Yeah, you wouldn't be able to progress forward. And what I've learned too, and I'll use storage, I'll pick on storage for a little bit, is that some of these vendors will certify on a specific version of OpenStack, but there might not be any backwards compatibility with past releases, and they may not be ready to release for the next release. And so those are all moving targets too. So, you know, what are your options at that point? I mean, other than, you know, choose solid fire. Yeah. No, well, I just told you. Sure, but it doesn't change the math, right? It doesn't change the math. And that's where we see the systems integrators, right? The Redaps and the WWTs, and that's where we see the folks who have the ability to look at their customer base and hear what they're being asked for, to hear all of the, but I wanna run Exchange, right? Whatever it is, right? We hear they get to see all of the complication and then get to call what it is that they need and be as prescriptive or as open as they want to be. And so what the customer ends up getting could be a, you know, could be as tightly constrained as here's your appliance and here's how much stuff it has in it and here's the software that you use to run it. Or it could be a full-on consulting project, but the people who we see on the front lines of trying to match those two up from the product side and the customer side are the systems integrators at this point because they're the ones that the customer trusts. And they've got more experience with all of that legacy. I mean, they've been selling that hardware to customers for the last 15 years. And they still wanna make themselves valuable moving forward. No doubt. And OpenStack's making it easy for them to be valuable, right? I mean, when you've got that many projects and when you've got that much stuff to try to keep track of as the funnel starts to widen on what is possible to roll up underneath a certified or a valid OpenStack integration, I think the partners in the field become even more valuable. They're getting rid of all of that and non-recurring engineering work of trying to figure out what works and which communities are responsive and where are we seeing development go from the corporate sponsors. They'll let them figure out that work and take care of that for their customers. There's only so much that I as a hardware vendor could ever do with that. All I can do is be willing to work with as many of those teams as possible. And I think there's only so much that we can do from an OpenStack standpoint other than give as much telemetry as possible around what are the projects? What's their status? What's their, how reliable are they? What feedback are we getting from the field? Those sorts of things to make the process of culling down and what goes into that actual offering to the customer easier. But I think this is where, why integration engine is a theme that's being used pretty often because it applies in multiple facets. So just like we just talked about, if you have storage rates and you have multiple storage rate types and people want to say, okay, you're supporting this support this as well. And we go to read apps to WWTs to do the SI work. Just like you want all 70 drivers in there just so there is a choice available. You need how many projects there are about, I think about 28 now that there's a choice available. If someone wants to go integrate what they need, they can do it. So I actually did a presentation earlier this morning and I had three takeaways from it. And one of my takeaways was a Swiss Army knife. And it was basically the fact that OpenStack is applicable to multiple workload types, multiple use cases because it has all these projects and everything. But because it has these projects, these number of drivers, it makes it very flexible, but flexibility also comes with complexity. Those options each have a decision point that you are now making. And it's not terrible, right? I mean, it's not a bad problem to have. So long as for the 20% of customers who are totally comfortable jumping in and saying, this is the direction I want this project to go because I know what I need out of it. And there are systems integrators or there are kind of that second level even the Cisco's IBMs, those sorts of people who are willing to package together and put together something to say, I'm not going to sell you OpenStack, I'm going to solve your problem. I don't know that all of those, I don't know that having all those pieces is a bad thing. I just think that it makes the process of even just defining what is valid OpenStack a lot more complicated than it was a year ago. On one hand, I feel like, you know, you can't underestimate the importance of a rock solid infrastructure as a service platform. But I am increasingly seeing customers asking for stuff that's sort of above the stack. Platform as a service. Like most of these folks are not even using infrastructure as a service yet, and they don't necessarily want to use platform as a service yet, they just want to know it's there. They want to be able to check a box on an RFP and be like, oh yeah, we got platform as a service through option X or whatever. I don't care, I sell storage. I sell storage. That's the easy way to do it, right? I love you, Bob. Feel free to use it any way you'd like to. Yeah, so look, there's stuff that happens below the stack. There's stuff that's happening above the stack. You know, I think the intent of core is make sure that the infrastructure as a service platform is rock solid. On the other hand, I also look at our networking stuff that we've created as a community and all the different options and underlay models and acronyms that only networking people can understand. And then I look at AWS and I say, huh, they have like two whole networking products or three whole networking products. Don't you work for Cisco? I do. Isn't that your fault? No. At what point do we, do we need, at what point do we focus on ease of use for the developer? Like at what point do we take the focus back to the developer? Cause I feel like, you know, a lot of this complexity is being driven by people who've traditionally worked in the data center and on infrastructure. At what point do we focus on the developer experience? Now actually, so it's a great segue because a big push going on in the community right now is we have representation and we have models how to get operator feedback. We're still missing the people who use OpenStack SDKs to write applications. The people who are developing and use consuming OpenStack, if you will, rather than managing it or building it. And so there's the application ecosystem work group which was just kicked off. And what they're doing is they're basically doing a hello world example of how to use these various SDKs and Go, Python, et cetera to consume OpenStack. At the same time, we're looking for, we have another group called the user experience group which just started as well. And they're looking at, okay, what's a workflow that people want? When I make an API request, a good example here is right now with Neutron, again, flexibility and complexity kind of go hand in hand, right? With Neutron, it's almost like it was written by people who know networking for network engineers. It's not meant for someone who's not a network person to consume per se. And that's where I think one of the differences in Amazon comes in. Where Amazon, you say, I need an IP, I have a virtual private network, VPC, a virtual cloud and I can just go in there, get my address block and be done with it. Nova Network had that workflow actually. So Nova Network was just giving me an IP and it would do it, but it was lacking all the different flexibility of layer three, layer two different controller types, et cetera. And so it's kind of like, and it's happening right now, by the way, is Nova Network is kind of merging workflows with Neutron. But I think, you know, to your point, getting that developer feedback is really critical. And so the community and the foundation are both actively trying to get more opensack developers to these conferences and summits to get that feedback. Actually, I think it's really important that we started the way we did though, because, you know, one of the things to your example, Nikki, is that, you know, Amazon totally abstracts the data center for all their users. And we're actually talking about people who actually have to build out infrastructure in the data center and figure out how to plug in whatever they get in an opensack cloud into possibly an existing network, possibly existing network topologies that are different from, who knows what it is? It's different in every data center, unfortunately, right? So I think that there's a bunch of value there where we've kind of hopefully built a technology where we're able to move forward and really just focus on a developer and the usability of the technology from the developer perspective instead of how do we get this technology into a data center and make it function and reach the internet? So. I wanna take some questions from the audience if you guys have any questions, or gals? Anything? Questions? Adrienne's back there. You got a question? Maybe you gotta know anything. Ha ha ha ha. Do you guys know Adrienne? He's the magnum guy. Hi Adrienne. Thanks for that, Adrienne. Thanks for magnum. It's gonna be cool. So thanks to the 101 contributors that made it. So much traction. Who are the companies that are contributing for the most part? Who's leading contributions for Magnum? Well there are 25, I think, companies who have contributed. So I can only hold about seven things in my memory at once. So I can tell you, of course, I'm from Rackspace. HP is in there, Huawei is in there. IBM is huge in there. So there's a lot of really great contribution going on. And it's not just the big companies that are easy for me to list off, but it's a lot of individual contributors even that are not affiliated. Who have stepped up and picked up features and fixed bugs. It's been amazing to see that. The level of excitement around, and I've seen more new contributors come through OpenStack Magnum. Like, so I see all of the reviews, right? I'm always every single day doing reviews on the project. And our CI system in OpenStack does something really cool where when there's a new contributor, it puts a welcome message in. So I know when I review that code that this person has never contributed to OpenStack before and they chose Magnum to do it. And I've seen that maybe 30 or 40 times where it's somebody who is coming in and they're contributing to this. We're growing our community because we're doing things that are new and exciting. And this is just a great feeling. It's good to see there's excitement there in containers. How do you feel about the Courier project? Well, we love it. We've been working with that team to get the specification really set and the requirements so that it's gonna work well with Magnum as well. So for those of you that don't know what Courier is, you didn't get to see it this morning in the keynotes, unfortunately, but it's a way to treat Neutron as a Docker remote driver for lib network, which is Docker's way of creating networks. So you can create a network using Docker through the Courier plugin. It's actually gonna create a Neutron network on the back end. So you don't have to have multiple networks that are stacked on top of each other. You're gonna end up with just one, which is pretty awesome. And at that point, the developer actually gets to control the networking experience. He can, or she can, yes. Awesome. I see how you got there. I was wrong, this is a networking, this is a... This is a container talk. So when we're talking about analysis process, it's interesting because going back to one platform message that's been used for bare metals containers and VMs. Even within that message, there's three things that we identified. But in bare metal, we've got multiple options. In VMs, we've got multiple hypervisors in containers. We've got different orchestration systems and even different container standards that not all of them are in the ecosystem yet. But like so all of those one platform choices have sub choices as well. And so again, that's where I think the one platform message really resonates well, but that's where it ties into integration engine as well. So what we want to do is we want people to make a choice to go with OpenStack Cloud, but then know that once you chose OpenStack, as things evolve in the day center, it evolves in different stacks come above and below, OpenStack is willing to receive and integrate them. It's the constant. It is the constant. Which is pretty amazing. And it's neat to see the number of projects that have followed suit in open sourcing their technologies to get community contributions to make sure that those things are also constant, which I think is incredible. Yep, absolutely. So all three of you interface with customers, users, community folks, if you had to give them one piece of advice about OpenStack just being this big beast and how you deal with that, what advice would you give them? When we talk to customers, we really start with that 80-20 rule, right? I mean we need to sit down with customers and figure out with them first and foremost how core to your business is the infrastructure that you run these applications on. And for some customers, it's very important and they are a different type of OpenStack user, right? Those are the people that we start figuring out how do we align with specific projects? How do we best spend the resource developer calories that you have to spend and where do we put them and which vendors do we align behind that sort of thing? For the rest of them who say the workloads are what matters and the workflows are what matters and the output is what matters, it's about how do we leverage all of the goodness that is OpenStack but do it as simply as possible, right? Because for them, the quicker we can do it, the more integrated that looks like, the more supportable, the easier that fits into their operational workflows, the bigger win it is. So we spend a lot of time with customers because there are, and it's probably no surprise to anybody, there are lots of customers who feel like they belong in that 20% who maybe even want to, their staff, people see how exciting it is to belong to one of the project teams and contribute and want to do that but we need to make sure that that's done in the context of how does this actually integrate in with your business and figuring out what's the right kind of OpenStack path for you to be able to take there? And once we figure that out, the rest of it honestly follows pretty naturally, right? If you are, the 20%, there's a pretty well lit path for how you get what you need out of it and if you are the 80%, there is an increasingly large number of customers or partners, systems integrators who will come in and be able to solve the problem for you with OpenStack being kind of that constant down in the middle with the rest of it around it. So once we figure out what type of OpenStack customer we're talking to, it makes the rest of that process and the success of the project itself a lot easier. For me, I'm thinking about, does the customer want to just be an OpenStack customer, an OpenStack consumer or do they actually want to be an OpenStack operator? And I think one of the things that BlueBox has determined to do is to remove the operational overhead for customers, right? So just trying, the question for a banking institution of whether or not they want to become cloud experts, whether they want to invest heavily into building out teams of people, infrastructure, data centers, to manage, to build cloud expertise or whether they just need to consume cloud that's private and in their data center or in their data center. So do you see value in running a cloud or just simply using it? Use the cloud. Use the cloud. We have very similar value props. In fact, some of our language on our respective websites might be exactly the same. I'm sorry. We don't want to talk about it. I heard Jesse from BlueBox use a private cloud that just works and I'm like, uh-uh, that was on our collateral like eight months ago. I'm not truly, I'm truly not getting into this. I hope you watch this video. Hi, Jesse. We'll sell storage to both of you. Yes. So I mean, I think starting with the business problem is definitely the first thing. And I think expanding it from OpenStack, I think start with the business problem, understand what are you trying to solve and how are you gonna solve it? And then once you've got how you're gonna solve it, figure out like, okay, what application architecture is it gonna require? And then use the tools that align with that application architecture, align with how often do you need to refresh that are you doing CICD? How often are you deploying? Because I mean, most of the keynotes we've seen for example, when it comes to CICD type workloads, most people even on, you know, let them on stage was using Kubernetes for example. So like understanding, you know, decomposing from business problem to application architecture and then taking the application architecture and going, you know what, one size does not fit all. I can actually modularize this and then picking the right tool for the right part of that application is how it would kind of decompose the overall thing. Amazing stuff. Good times. It's never boring. Never boring. And you know what's cool is once you get OpenStack in an organization, it pretty much spreads like wildfire for what I can tell. And I think a lot of that just has to do with the cultural change that OpenStack helps drive, especially in the enterprise. You know, gone are the days of, I'll have to request through a ticket and wait for weeks or days or months to get a resource that self-service sort of agility that all the folks are seeking. You know, I think that comes in through OpenStack. And I think it's a powerful driver for the cultural change in business. And every day it gets better. Every day. And every day we figure out, collectively we figure out better, what are the workloads we're servicing? How is the most efficient way of doing that? How can we be the most productive that we can be with the tools that we have? So it's good, but there's always forward movement, which is more fun. I wish we could have like a group hug with all 39 hard developers. We can start right here. I love you guys. Competitors and friends all at the same time. I just sell storage. We have three minutes left. Any questions? He's in a shirt that says, I just sell storage. That's it. I'm the infrastructure guy. Sure. See, you talked about 18 month development cycle and you're tracking what goes into those roadmaps. How many people have adopted from the previous versions to, I mean, do you have a distribution? So, yeah, so great question. So basically the question is with the eight month, three release cycle, 18 month roadmap view if you will that we're building, how many people are we seeing move version version? And I think those are two separate questions. So the roadmap is more forward facing information of people trying to decide when do I want to move from a user, from a data perspective, the user survey actually contains a lot of data about which releases people are using. And generally I would say 70% plus or within minus two of the current release is what seems to be a trend. So it's not a specific release. It's usually within N minus two you cover about 70% of users. Actually I had a question about that for you as well. So I was wondering, you talked about building out this roadmap. I'm really interested in the product working group. But you talked about building out this roadmap and getting in front of the eyes of developers but I didn't understand exactly how those things that are on the roadmap in the future are getting action. So it's actually two different things again. So the roadmap we're doing is not building the roadmap. So we're not building the roadmap. What we're doing is we're actually collecting what the roadmap is from the teams and just aggregating that information to make it available. What we're doing to input our requirements and user feedback into the projects, that's actually the user story side. So we're using user stories to share with the project teams and hopefully working with them to identify, you know, it's the feedback loop. It is. Communication, go figure it. Oh yeah. Fantastic. And actually Adrian, since you're still here, how's that working out? Like as far as the roadmap stuff, like did we do a better job this time of collecting data and what was your perspective as being a PTL in this funnel and feedback loop of user stories and roadmaps? We have one minute left. In all honesty, I have more use cases than I can actually execute on. So it's exciting to see how everyone wants to use OpenStack. And we honestly haven't sorted out exactly what we're gonna do in the next release. That's what we're here this week to do. But it's great to have real data and it's great to have folks that are showing up to share with us exactly how they plan to use it. So we'll see. Great. Thank you. Thank you all for attending. If you have additional questions, you can catch us outside or follow us on Twitter. On the tweets. Thanks everyone. Thank you. Thank you.