 Welcome to the OpenStack Summit half-day track. I've already seen two great presentations today. Somebody's mic on? Who's that next door? So today, we'll be hearing from some folks about using OpenStack in the actual real world. Now, we have our DevStack instances, and we spin those up and try it out. But how does OpenStack actually perform when it's asked to actually put the rubber to the road? We're going to hear from folks from a number of different perspectives, both the technical and the business side, both folks that are deploying clouds, folks that are building solutions on top of clouds, and folks that are using different components of the OpenStack system to deploy specific solutions to meet very specific business needs. So these are our customers that are actually using OpenStack in the real world. So a few things. We're going to have some folks come up. They're going to present for about 10 minutes. They're going to give you an overview of what they're doing with OpenStack and how they're leveraging OpenStack, the challenges that they've faced, and how they've overcome them, what they feel they need from the OpenStack community, and what they most appreciate about the OpenStack community. After the presentation, we're going to have a Q&A session where you're going to be able to come up and ask questions. You can either come up to the mic here, or you can tweet using this hashtag here, hash OpenStack real world. So first, I'd like to introduce you to Josh Estelle from the HP Public Cloud. And he's going to talk about HP Healy in Public Cloud today, about how leveraging the OpenStack technology to actually deploy one of the largest OpenStack public cloud deployments in the world today. So please give your round of applause to Josh Estelle. Can everybody hear me? Hi there. Hi. Good afternoon. My name is Josh Estelle. I work for HP Healy in Public Cloud, formerly HP Cloud. We just had this, if you were here earlier, they discussed the changes that they've made around that. My official title is Support Operations Consultant. Basically, I talk to the customers so the engineers don't have to, right? I have people skills. I'm excited to be here. This is my first summit. I'm trying not to be overwhelmed by all the incredible information that's available. I've been walking around all day having a great time. A little nervous, you have to forgive me. HP Healy in Public Cloud support team is based in Austin. We're about 25 people, all told. I've been with HP for about two years. I came from a banking IT background. Working with OpenStack has been an amazing experience for me. So why am I here talking to you? I was approached by a colleague and asked to talk to you briefly about what it's like interacting daily with customers of the HP Public Cloud. The support role might not always be considered mission critical. But being as strong involved support team affords not just us, but the entire organization, the HP Cloud organization, the opportunity to see how customers actually use the Cloud. I would say that we have an understanding of how the gears mesh, right? And what does that mean? Well, HP Healy in Public Cloud is comprised of a lot of incredibly, incredibly intelligent people, right? We have our Nova engineering group. We have our Linux and virtualization team, Neutron. We have the console team, systems engineering, the people that actually hold the Cloud up and make it work. But from our perspective, I guess to say, the support team can answer questions in one interaction like Glance API syntax, send or backup procedures, Swift metadata and ACLs, right? So we can kind of do that all in one shot. Now, that might sound like it's a bit of a boast, but I think it gives us a novel perspective. Let me hear. So supporting open-text software in the wild affords us a unique opportunity to see how it is being used in the public cloud space. What does that mean? Well, I guess put simply, it's the difference between how it can work and how it does work for customers, right? So I remember in particular when we first enabled Nova Rescue in our environment. Nova Rescue, people are familiar with it. It's a way to actually mount a problematic instance onto another instance and mount it as a storage volume and access it to fixed configuration file issues like that. So that was a bit of a tough sell for people that were new to the cloud. But I use that example because it seems emblematic of the kind of shift in thinking from a traditional IT point of view that was required by our customers, right? So as I said before, there's a lot of gears meshing, a lot of services. Like you say you want a Buddha-persistent instance with a custom image and a static IP, right? That's four services interacting. So you've got Nova, Glantz, Cinder, and you've got Neutron. What could possibly go wrong, right? From the customer's perspective, right? So our goal is not simply break fix, nor do we manage in the public cloud, but we don't strand our customers, right? So we do, as with any support organization, the work that's salt, we do our best to educate our customers and try to straighten out the learning curve, right? So translating what we learn by focusing on customer experience, good and not so good, and the positive changes upstream. OK, so we realize that OpenSec is a living thing, right? It's not perfect, right? There are some rough edges out there. Like the journey of Nova from Diablo to, I'm sorry, to Grizzly to Havana for us was a learning experience, right? We have seen OpenSec mature significantly. It's gratifying to think that issues that we encountered and identified and raised up through our ticketing system that support to our engineering teams were eventually filed in Launchpad and crunched through and resolved by the greater community, right? So when we see those changes come back and they're deployed into our implementation, it's full circle and it kind of makes us feel proud that we might have had a hand in that. So integrating our experience into the healing in public cloud strategy, we are users of OpenSec ourselves. So at this point, we've matured as an organization. Going forward, we'll be part of, as it was explained earlier, we'll be part of the broader strategy to leverage OpenSec technology. We'll be the public option where services can be tailored to a customer's overall needs, integrated into a wider array of cloud solutions based on OpenSec technology, right? So the fact that we, meaning the entire HP Healing on Public Cloud team, have this experience under our belt, means we can feed it back into the new Healing on concept, right? So where some of the other components like private managed clouds can benefit from our experience. Who are our customers? Well all kinds of customers use the HP Public Cloud or the HP Healing on Public Cloud. Here's a couple that stand out, right? So we have value seekers with costly workloads. Happily we have a core group of users that are actually using Public Cloud the way it works best, right? So they're utilizing automation to build and manage typically short-lived but dynamically scalable workloads, right? They've committed engineering resources up front to master the ins and outs of OpenStack. Now they say this works, and it works good, works well for us. How can we apply this to other things that we do, right? So it's now central to their thinking and it works well for them. This, the traditional enterprise. This is another target demographic, so to speak. We're engaging this one more and more, right? So one in particular I can use it as example, they're coming from another cloud provider. So they already use a lot, but they already use a lot more traditional HP services in-house, right? There's an existing relationship that we have with these customers. So for them there exists a kind of dichotomy between what they do inside the walls of their organization and what they do in the cloud. So the concept that we're going for here is by using our service, they'll be able to unify and align their compute requirements, right? Basically, the promise of hybrid cloud, being able to move VMs in and out of the cloud and bursting workloads as needed, right? So it's kind of a one-stop shop. Okay, so let me go to the next slide here. And these are just a couple of things that I wanted to talk about, just kind of general things here. As Chris Frank spoke earlier, I don't know how many people were here, he kind of gave a flowchart of the services that we offer. So basically, a lot of customers come to us the first time when we interact with them, if they're not really kind of onboard with the cloud thing, they'd say, here's my image, make it cloudy, right? And we say, wait, we understand what you're trying to do, but here's object storage, here's block storage, here's load balancing as a service. All of these things can work in concert for you, right? So that's one of the things that we try to stress when we're interacting with customers at the support level that if they're not kind of with the idea of cloud, that we try to educate them on all the services that we offer because it basically adds value for them. Neutron, what's that, right? So Neutron is incredible, there's no doubt about it from our perspective, from the customer's perspective, they love it. It complements, computes, in exactly the ways that a lot of our customers consistently asked for in our earlier releases, like our first release, our 1212 release was based on Diablo. For new customers, it adds a layer of complexity that takes some additional cycles to master, but once they do, they quickly realize it's potential. And I get to work with customers on a daily basis, some of whom have built amazing, amazing infrastructure, network infrastructure in our cloud. I get to see it because I can see, when I'm troubleshooting something with them, I get to actually see a kind of a layout of what they've gotten. Sometimes it's truly amazing, right? So embracing fundamental change and looking over the horizon, right? This is vague and cliche, it is, but it's kind of the big one, right? So for a lot of businesses, this is kind of a fuzzy thing, this cloud thing is kind of fuzzy out in the distance. Like I said, it came from a banking background and that IT is ancillary to their mission. So they're still kind of getting up to speed with it. So while we do everything we can for them, they have to commit. And the good news is, from our perspective, that change is, it seems to be underway. So that's pretty much it for me. Let me sit down here. Thank you very much. Next, we're gonna have Chris Myers come up and he's gonna talk about how Gigaspaces has enabled him to deploy applications in the HP PPS group to the cloud and how Gigaspaces enabled him to do that effectively using their product called Cloudify. So round of applause please for Chris Myers. Good afternoon, everybody. So first things first, let me tell you, being a geek, it's tough being in front of people here. I know how Jocer's feeling. Yeah, pardon me. Part of my professional development was that if I could get up in front of people and talk, my boss would pay for the trip. So instead of everybody taking pictures of me, if I could get everybody to smile, now all I have to do is get off here without falling over and I win the bet. So again, my name's Chris Myers. I'm from the PPS CTO office and with me today I have Natty Shalom, founder and CTO of Gigaspaces. We're gonna talk just a little bit today about how internally we're using HP as a customer. So just like everybody's sitting out here, that's a customer of the HP Cloud solution. We actually use it internally as well. And so I have a lot of insight as to using the tools just like our customers do. I don't get to call Josh directly and say, hey Josh, my stuff is broken. I use the support tools and really we're trying to do that for a lot more of our solutions so that we know how our customers are using our tool set. About a year ago, we were hit with a fairly significant challenge. We were a brand new team formed within HP across the PPS group to look at consolidating operations and how we wanted to operate those solutions and how we were gonna take more of our products to the cloud. We were actually, if that wasn't big enough, what they said was, we want you to move everything out of where you're running it currently and move it onto HP Cloud. That was about 15 different solutions. Those 15 solutions were back ended by about 40 different services such as databases back in content repositories and other administrative functions. You know, we're HP's a big company. We've got 320,000 employees. Obviously, we have quite a few developers. Last count I heard we have approximately 50,000 software developers within HP. That means we've got guys doing Windows. We've got guys doing Linux, OSX. We're doing .NET, Java, C Sharp. You name it. If a guy's written a language or a lady has written a language, there's a pretty good chance HP's delivering a software solution on that product. As to make matters worse, one of the new requirements that they passed on to us was that one of the solutions that we were gonna deliver to HP Cloud had the potential on launch day to have 16 million addressable printers connecting to the services. So from the ground up, we knew that we had to be scalable. That was pretty, anytime you move to a new platform, you're gonna be exposed to new technologies. With our team being very new, everything that we looked at on HP Cloud was new. The DNS, the networking, pretty much we were figuring out from the ground up. But pretty quickly, what we really honed in on was that we needed to know how to handle our provisioning and orchestration. Internally in HP, we do try and do continuous integration, continuous delivery. We're starting to do the continuous development and deployment. And we've gotten pretty good about doing it with a single pipeline. But we really, because we're a consolidated operations team, we really needed to have a standard pipeline that we could use across the board for all 15 products. That meant that we couldn't have one-off configurations. We couldn't have different ways of managing it. It had to be the same pipeline for all of our products. We started looking at different solutions that we're gonna be able to handle some of the provisioning needs that we have because we really wanted our developers to be able to provision compute resources out there on HP Cloud the same way that operations was gonna use it at production. We started looking at a lot of the tool sets that everybody's familiar with. We looked at heat and salometer. We looked at building our own. Again, we're a team of geeks. Everybody said, we can build a better mousetrap. We can build a better automation. We can do provisioning. We can do monitoring. But when we looked at our time frames, we just didn't have time to build brand new solutions. Heat and salometer. Within HP, there's a pretty hard push not to duplicate effort. Obviously, the HP Cloud team is doing some great work pushing out new services. The OpenStat community is pushing out features daily. We did not want to rebuild another solution that might be coming in the community in the very near future. So what we ended up doing was going to HP's partner portal. And if you haven't seen it, it's a lot like the new marketplace that OpenStat announced today. It's a list of partners that are working with HP Cloud. And it can really give you a real quick leg up on how you're going to build some of your solutions without having to build them over from the ground up. Pretty quickly, what we started to look at was the Gigaspaces Cloudify solution. Number one, it was open source. Almost our entire stack is based on open source. We've worked, anybody who's been within HP for a while, we've definitely had the opportunity to work on proprietary software. We've worked on proprietary operating systems. But there's a very large open source community within HP. Of those 50,000 developers, thankfully, I don't have to support all 50,000 of them, but I've only got a couple hundred of them. But across those 50,000, we've got several that are now pushing directly back into the OpenStat. So they're pushing features, they're doing bug fixes, they're doing code reviews. Cloudify's product was OpenStat, or was open source. And so that gave us a really good, in-depth look at what the product was doing. Additionally, if you think back about a year ago for HP Cloud, we were still running the 1212 release. And we'd started hearing rumors of 13.5, it was going to be out there, what were we going to do with it? As we started talking with the HP Cloud support folks and trying to figure out what their product roadmaps were, the Cloudify kept coming up internally as well, that they were working already with the 13.5 release. And so what we started to notice is with a lot of those partners that are listed on our marketplace, they're also working very closely with the HP Cloud R&D. Because of working with Cloudify and their prior work with HP Cloud, we were actually able to deploy directly to that 13.5 release. That basically saved us about two months' worth of engineering time. Across a team of seven guys, 15 products, I mean, save in two or three months, that's huge. Between needing to develop that product on what's now a legacy platform and then have to re-qualify it on the new one, that's just not something that we could take on. Going to the Cloud is supposed to be faster, it's supposed to be more cost-effective. So there's a few numbers up here. I'm gonna run through this real quick and then we'll get to a quick demo. Between Cloudify, the HP Cloud solution and OpenStack, we're currently managing about 30 HP Cloud public accounts. We do the same thing that you guys are using. We're paying the same exact price. We're using the same tools that you guys are. We're managing about 500 continuously running instances and we've seen peak deployments with Cloudify and OpenStack of 1,400 per day. Now, full disclosure, here about three weeks ago, we actually doubled that number to about 2,400 by accidentally having a provisioning system run away. We're doing on-demand deployments now of those 15 applications. We successfully deployed those applications. We've got the 40 separate components running. We're running high availability databases and just about every other service on OpenStack. The current instances of Cloudify, we're running about 100 compute instances per management cluster. We've been working very closely with Cloudify to get those numbers up above 1,000 with the 3.0 release. We're really looking forward to what that's gonna bring to us. Again, we've got now hundreds of developers using the products. Our developers, one of the really nice things about this was that the recipes that we write with Cloudify, they're all based on Groovy. Most of our developers now, they're intimately familiar with Java. We can take any guy from pretty much any language. We can put the Groovy files in front of them and they know exactly how our provisioning is working. It's in our source control. When a developer does a build on their box and it connects remotely to Cloudify via the REST agents, it's deploying with the exact same recipes that we're now deploying in operations. So I'll give you just a real quick demo as soon as I figure out where the cable went. And Natty will be here in the next presentation to give you a more in-depth overview of Cloudify. So one of the really nice things about Cloudify, we can do our connections via SSH, but everything that we do on SSH is available via REST. And so don't take it that we're sitting here every day. Operations guys back here looking at black screens with green. I'm missing my green here doing SSH to deploy the things. We don't do anything here. This is mainly for troubleshooting, but it gives you a pretty quick look. One of the first things that it does when we connect to Cloudify is I mentioned that all of our deployments are in our source code. When we start a deploy and we tell it which applications we're wanting to use, it actually collects up those recipes. It collects up packages and configuration files that have been set up by our deployment scripts, pushes those directly out to those Cloudify managers. Once they're out there on those managers, they're running in a highly available environment. We're using the compute storage and networking that's running out there in HP Cloud. We just finished deploying the node. We're refreshing the Horizon console here to pick up that the new instance is going to show up. We'll next go over to the Cloudify manager, which if you've used other, if you use some of the Cloud provisioning systems, actually we'll back up here and just show you. We're actually using a lot of the new networking function out there on HP Cloud. Just a word, don't overcomplicate it. You can see that we've got front end load balancers and back end load balancers and we've got back end networking and we've got our databases running off of there. And at one point we had about 20 different networks here and now we're starting to consolidate them down. It's really great that we can make that nice and secure but do what you need for your product. The one piece that we missed here was when we go into the Cloudify manager, you'll actually see that we've got monitoring, we've got metrics, we've got dashboards. So a lot of the things that some of the traditional operations teams are gonna wanna look at, you have them all there. Again, everything that you can do in the Cloudify manager, you can get via REST. That's actually the really powerful thing. We're using Cloudify to provision all of our compute resources on HP Cloud. So instead of us working out how we want to handle auto-scaling with our compute instances, we let Cloudify spin up our compute instances. We let Cloudify spin up our networking. They're using the same API calls so that we can troubleshoot directly back to the OpenStack solution. We've got the API calls that when we contact support we can tell them exactly what we're doing. Couple of the other things that you're seeing here is that we've got access directly to the logging information from the compute instances and now we're back looking at the hosts. And then I think the last thing that we'll show here is the app catalog. So, or actually this is the partner portal. So just like the marketplace out there on OpenStack, go take a look at this out there on HP Cloud if you're using it. There's a really broad range of solutions out there that are set up specifically to help you deploy your solutions faster. If you don't have to build it, if you've got a workload that you need to migrate directly to HP Cloud, take them out there. Thank you so much. So as a Cloud platform, I think that you can tell that you've been successful when folks can build products on top of your product. That's certainly what Gladionette has done here. Take a space. Next actually is Gladionette. And I'm going to invite up Mike Gaswell from HP IT. He's going to discuss how he's actually used the Swift component of OpenStack to deploy an enterprise-grade Dropbox-like replacement. Instead of letting folks upload their stuff to Dropbox, it turns out people really need to transfer files to be productive. People are dealing with more data than they ever have before. And so we're going to learn about how we've leveraged the OpenStack Swift component to implement that Dropbox-like application. So, Mike? Is that coming through? How about that? So I was going to one up you and do a selfie in front of the screen there, but I won't do that. So what I wanted to talk to you today about was utilizing an OpenStack Swift infrastructure to supply a Sync and Share service. I do. Can everybody hear me? I can hold it. So to talk to you today about was using your OpenStack Swift infrastructure to create a Sync and Share service for your organization. So what we were trying to do, we were given a challenge as well to stand up a service within a very short amount of time. We wanted that service to allow our employees to bring any of their devices to the service. We wanted to offer file sharing for our employees as well as a collaboration tool for them to use so that they could share files between each other within groups with partners, vendors, et cetera. We were also looking to secure the control of that data, leaving the organization by creating an on-premise solution. We also wanted some flexibility in the solution to be able to burst to many different endpoints, be it the public cloud or our on-premise solution. And we were also looking for a secure external solution that they could hit from any location wherever they were at. The initial estimates for our solution were to provide it for 150,000 employees, giving them 25 gigabyte quotas. So what we did is we did an initial investigation into several different third-party solutions out there. And we actually came up with a gladness solution running on our OpenStack Swift infrastructure. The OpenStack Swift infrastructure, given the types of data that our users were going to be storing, it provided a perfect data repository for the non-structured data that the user would be putting onto the sync-and-share solution. So with provisioning, because OpenStack Swift has a RESTful interface, we were able to tie it into our cloud provisioning model as well as we were able to tie it into our cloud provisioning model to allow Swift accounts to be created immediately through the REST interface. We were also looking, you know, with Swift being as durable as it is, we needed that high availability that Swift was offering for the solution. We also were wanting the transport security of SSL and Active Directory integration as well, or in this case, for Swift, it was LDAP integration. The other benefit to using the OpenStack Swift infrastructure for us was the horizontally scalable nature of the product. With Swift, we can actually just add additional nodes into the cluster, either in the proxy layer or into the data layer to accommodate for either concurrency needs or data needs. So with sync-and-share solution, we specifically looked at several different products. And again, wanting our employees for any of them to be able to participate, because HP does not supply mobile devices to all of its employees. We wanted employees to be able to bring their own device, be it an Apple device or an Android device, whatever they had, tablet, laptop, and then they would be able to participate. So that was one of the key components that we looked for when we were investigating different products. For collaboration, we wanted a very flexible file sharing solution that would allow employees to share inside and outside the organization, therefore being able to basically send an email to somebody outside of the organization, sends them a link, then they get access to that file through the GLAADnet infrastructure. We also looked for a solution that would supply the user security that we wanted to implement, which was to have this tied into our Active Directory so we can control it through groups and through their Active Directory identity. As for data security, we were actually looking for different solutions. The components we were looking for with those solutions were data at rest security and SSL encrypted. So the GLAADnet solution actually allows us to do data at rest encryption through that solution on an endpoint basis. So when the user hits the GLAADnet infrastructure, all of the information they send up is then encrypted on disk. And it cannot be accessed through the actual Swift endpoint. With flexibility, we wanted the capability to burst to many different endpoints. So we actually have an on-premise Swift installation, but we also wanted the capability in the case of if we were running low on space or a situation similar to that, then we would want to be able to burst to a different endpoint, such as the HP public cloud. So we looked for that in the solution that we were trying to push out. So branding was one of the major components of one of the major things that we looked for with this particular solution. We wanted a solution that could be fully branded under the HP name. And so the GLAADnet solution offered this branding for us, as well as GLAADnet was very willing to do any customizations to the software for us. And I do have a demo that we can run through. OK, so this is what it looks like for HP internal employees as well as external people that get shared with. So it does have drag and drop features. So this is the web interface. And you can actually drag and drop files into the web interface. And then there's also the point of work. So there is an upload feature right there that allows you to upload files or you can upload entire directories. And so with the product, there's several different components that are great here. So there's an integrated file viewer. So basically, you can highlight a file. You can click on the file viewer, whether it's Excel or Word. Basic file copy from folder to folder. And then there's a file move feature, which would allow you to move files from one folder to another, not leaving a copy obviously. And a rename feature. And these are just the basic features of the web interface. And of course, delete. So all of these files, basically, they get uploaded through the GladNet infrastructure, and then they're stored into the object store. The way that we have laid this out within HP is we actually have several different object storage accounts. And then within those accounts, we create containers. And inside of those containers, those containers are created through the REST API. Those containers are created based off of unique identifying information for each individual user. But again, the data can't be read from the object store because it's encrypted. So this is an example of the sharing that goes on. So and what it is is an email address gets typed in. And then you can go out to that person. That person goes out to their inbox. They cut and paste the link to that address, at which point they are then granted access to the file. And you can see from the file viewer that it's the exact same file that I shared with them. And this is the desktop client. So what it does is this actually maps a drive to the object store from Windows. So in our case, we have it set up to be the H drive. And that actually shows up in Explorer as an H drive maps directly to the container in the object store. And you have access to your files. And you do get the same functionality. Actually, you get more functionality out of the desktop drag and drop. You also get a management console which will show you different features here. So this is one thing that you can also do is you can actually attach an entire folder. So this folder would be synced up similar to other sync and share solutions, public options, where you can sync an entire folder. And no matter what you put in that folder, it gets synced. That's what this particular feature does. Great. Thank you so much, Mike. So another round of applause for all of our OpenStack users up here. So now we're going to have an opportunity to ask some questions. I'd also like to introduce Franklin. He's actually a VP at Gladinet. And he's going to be able to answer any questions you might have about the Gladinet file sharing solution. And he'll be available afterwards as well to answer any specific questions about that. But there's a few questions that I'd like to ask before we get into asking your questions. How did you guys hear about OpenStack and what was it about OpenStack that made you realize that OpenStack was a platform that you wanted to get involved with? Why don't we start with Franklin? Hi, guys. I'm loud. So for us, it was all about being open. So we had a vision from early on of presenting a falsely can share a solution for enterprises. And we thought the way to do that, well, let me back up a step. So when we first released our solution, we noticed that a lot of interest from customers was based on backup use cases. And then we quickly realized that was an issue of trust. So people were kind of thinking, well, this cloud thing's cool, but I don't know if I trusted that much. So I'll put some backup data up there and see how that goes. And then the next trend we noticed was a move from there to collaboration. So the whole BYOD craze, driving a lot of adoption of consumer-based solutions. Now, in between those two steps, we thought, well, if we make our solution open so you can choose any cloud service on the back end, then that'll help people trust the College of Memorial. Don't be vendor lock-in, et cetera. And what we quickly saw happening is with OpenStack, a lot of the issues that we saw that we're trying to address with our open ideas were encapsulated within OpenStack as a private cloud solution. So we quickly started focusing on OpenStack. And we've seen a lot of enterprises coming to us asking for these signature capabilities based on OpenStack. Thank you very much. The sound people turn on the mic, please. I just wanted to add a few words about that. I mean, we started early on when cloud just burst into the world. We started with Amazon. And I think one of the things that was very worrying to us is that everyone who worked with Amazon as a partner know that the way they work and operate is really it's my way or the highway kind of thing. And for partners, that's not necessarily a good place to work, even though there is an open ecosystem, but it's actually not really an open ecosystem. And second, our customers are enterprise customers which need the control over the environment and the infrastructure. So the my way or the highway approach didn't really apply to all of them. And so there was also this problem with the gold market strategy that we had with enterprise customers versus going with an Amazon approach. So I remember the early days when OpenStack came to the world with Mark Cullier and his team in Rackspace back then when the idea just came up, I think that kind of light the ball on my end. And that seems to be the right thing and the right time. And that's how we kind of plugged into that. So would you say that the lack of Amazon API compatibility is an issue or is actually beneficial to the growth of the OpenStack ecosystem? I think it's naive to think that there would be one API that covers them all. I think the solutions of how we deal with compatibility between, let's say, OpenStack and other clouds, including Amazon, is not necessarily at the API level. It's on the templating level. For example, if you do look at what heat is doing, what we're doing for a long time is actually making the packaging of the application, the templating of the application, portable. Which means that the underlying API can be different, but the actual blueprint of the application can be portable. And that's the layer in which I think compatibility should be kept. There is obviously the TOSCA project that is ongoing to actually make that blueprint more standardized. So I believe that this is the place, the right place to look for compatibility, not necessarily at the low-level API. Okay. So Josh, how long did it take HP Public Cloud to deploy their first instances and be able to bring up your first compute controllers? Well, to be honest, I wasn't around when that happened, but I mean, I can give you an idea. I guess it was, the planning started, I guess, in, was it early 2012, maybe late 2011? And there was decisions made. This, the results that we see today with HP and OpenStack were, this is the result of the planning way back then, I guess it was, I think it was late 2011 when they got together and they said, hey, this is something we can bet on. We believe in it and that's, like I said, we're at the point where we're realizing the same kind of things that Linux brought to computing, I think OpenStack is gonna bring to virtualization and I think that's where HP bet on that back in late 2011 to get the ball rolling. Thanks. Mike, what was the biggest challenge that you faced when deploying Swift? I would have to say probably the biggest challenge that we faced in deploying Swift was, it probably was more, so I worked for internal IT. I worked in the storage group and when we decided to go with Swift, we decided it was because we had specific groups coming to us wanting to do very specific things that traditional storage didn't really have a solution or a good solution for. And so I think for us, one of the most difficult parts of deploying Swift was probably more lack of resources on our side and coming up to speed as fast as we needed to because we spun it up pretty quick, so. So we're all doing some pretty interesting stuff with OpenStack, you know, OpenStack certainly developed a technology platform to do infrastructures of service. Do you feel it's in OpenStack's benefit to move out into the platform as a service to start looking at higher level abstractions? So, Franklin, I'd like to hear your answer first. I have no idea. I think, how should I put this? So as we move towards more and more abstraction, what I can say is that I'm drawing complete blank, that's what I can say. All right, how about let's hear from Geek of Space. Sure. Yeah, so actually that's a very favorite topic of where I would say the boundaries of OpenStack should begin, where it should end, and a healthy discussion, I believe. And the question comes down to, are we looking into one solution for a problem or do we look for an ecosystem of solutions? And what we'll see, I think, in the history is that as we go up the stack, taste becomes an important thing. Look at web framework, for example. How many frameworks do we have to develop web application? How many frameworks do we have to develop mobile application? Do we have one or do we have multiple? Are they overlapping? Yes. Is that good? Yes. As we go downstream, closer to the infrastructure, usually we tend to look for more standardized approach and so forth. So in my view, the approach that has been thought by some that everything needs to be owned by the stack and needs to be part of the distribution and needs to be done in a certain way, that's a wrong approach. I think that the OpenStack should have enough in there to allow the ecosystem to embrace it and build even competing solutions to some of the stacks because competition is a good thing even for the internal thing within the stack itself. And I believe that the core thing needs to remain owned by the stack, but everything that is going as you go up the stack needs to be, even if it's in the stack, needs to be open for competition, needs to be open for other solutions that will be using those core services and not expecting one solution as part of the distribution. If it's not upstream, then it doesn't exist. Thank you. And I'd like to hear from Chris. Chris, what do you think is necessary? What do we need from the OpenStack community for us to continue to see the success of OpenStack in the enterprise and continue to see the success in the community that we have? What do you think is necessary? So I think a lot of it is what we're seeing today. The OpenStack community is just that. It's a community, it's growing, it's thriving. They're taking requirements from the enterprise and all the way down to the small startups. I think that OpenStack needs to continue to focus on the infrastructure layer that they're building out. There's so many challenges and so much cool technology that's going on in the world of the hypervisors and the compute instances and storage and networking and the whole software defined model. If they continue to focus on that level of the solution, we're gonna continue to see adoption from enterprises, from little companies. We're gonna continue to see businesses starting to build on top of the OpenStack. We've got a couple of really great examples up here of companies that are using those OpenStack solutions to build a business. And so that in and of itself really shows that OpenStack's doing what they need to continue going in the coming years. So Chris, where do you see OpenStack in the next five years? My, honestly, I want us to, I want to see us take down the proprietary providers. I love open store software. I like the ability to go in and actually see what's the problem that's causing me an issue I like to be able to go in and figure out a way to fix it. And so in the best world, I think it would be that OpenStack and potentially forks that were open source would be what's taken over the world. And I think Franklin had something that he wanted to add. Yeah, real quickly, I think also, so of course we're doing a lot of the right things. I think right now we're still in the early adopter phase where there's a lot of technical innovation. I think what we need to see more of is helping businesses navigate solutions. So the entire stack from application all the way down. So this is not just infrastructure, a platform, but what are my end users actually gonna do with this thing in my business? And how do I figure out who I turn to for help? If I want enterprise, Faustin can share, how do I find that? How do I find backup? How do I find whatever it is that I need? So thank you so much to all of you for participating today. So before I let you all go, I just want to give a shout out to the HP booth folks that are here. And they'd really loved if you could come down and check them out. We're also gonna have an expert prior starting at six o'clock where we're gonna actually have some of the HP's core contributors to the OpenStack community there to answer any questions you might have, as well as some additional experts on how we use OpenStack in HP, particularly with regards to our HP public cloud. So come check that out. And also we're gonna be giving away a 10 inch slate. So it's a tablet running the Android operating system. Come check that out. You wanna be down there a little bit before six o'clock so you can get a ticket. We're doing the draw at six and we're gonna be doing a draw every day at the booth. So get your ticket and that ticket's gonna be good for the rest of the week. So if you don't win tonight, we'll have an opportunity to win for every each day. We're gonna be giving away two of those tablets. So thank you so much for joining us and I hope you enjoy the rest of the day. And we'll be having a next session here in about 15 minutes. Thank you.