 It's coming out of the speakers. There we go, perfect. All right, so thank you all for joining me. My name is David Easter. I'm the product line manager at Morantis. And as a product manager, I'll let you know that some people think of what's the worst possible thing that can happen is failure. And actually, for me, the worst thing that can happen is to succeed, but succeed only once. So you want to be able to succeed more than once. And so my presentation here today is about what happens if you're successful in your first implementation of OpenStack, then what happens. So I kind of go over. I've only got 15 minutes, so I'm not going to give you all the answers. But this is more of a teaser. Get your mind and gear. Think about things that you can take with you to other parts of the convention today and tomorrow. So today I'll cover the challenges that you have. I kind of cover the ideas that you've run into when you've been successful only once. Talk about once you've been that successful once, and you're asked to repeat yourself and be able to be successful more than one time, what are the next steps you need to do? And there you need to think about deployment. So prior to the installation, what are you going to do before the deployment? Make all the choices you need to make. Then there's the actual deployment itself. And what are you going to make your choices about how to do the deployment? Then there's the once you've actually deployed it, how will you make sure that deployment is successful, how will you care and feed and maintain that deployment moving forward in terms of operations and ongoing. And then when you get to the next version of the situation, how are you going to patch and upgrade the deployment that you've done? So here's the challenges. So OpenStack is an amazing technology. It's an amazing project. It's an amazing community that's come together to be able to create it. But you talk to many people. It is very difficult to install at times. It's similar in some ways to having a child. It's fun at the very beginning when there's months of waiting and pain and difficulties. Finally, something comes out. And then you've got another 21 years to be able to maintain that. So you have to raise it from there. So it's very difficult, it's very challenging. The documentation certainly is there on the community. But it's not always the easiest way to be able to understand how to do your deployment. So there's challenges there. Next part is that once it's actually deployed, there's very limited resources and limited information that's out there in the community about how to keep your operation up and going, how to make sure it's running at peak efficiency, how to make sure it's the most efficient it's there. You want to be able to make sure that you're meeting your SLAs, meeting your business requirements, and what's out there in the community to be able to help with that. After that, we find that, again, successful only once is not sufficient. Organizations and businesses are doing multiple clouds even within the same company or within the same organization and need to be able to take that success and be able to repeat it over and over again and do it successfully every single time. And then finally, once you've actually deployed a cloud, depending how long it took you, by the time you've actually deployed a particular version of your cloud environment, there's probably a new version that's already available, whether that's a major version depending how long it took or even minor version. There's versions that come out every few weeks or so and what are you going to do to keep up with the community a very fast-paced and accelerated and very invigorating community? How do you keep up with what they're producing for your environment? So prior to installation, so in your first cloud, you probably cobbled together some hardware and you found some old devices in your closets and got it all together and were able to put it up. Once you actually are asked to duplicate that and create a production cloud or create another more than a POC of your environment, it's going to take some time to get the actual physical hardware to be able to do that successfully, whether it's actually at the company already or you have to order it and buy it and bring it in. So one of the things that you should think about when you're starting to roll out your second and further clouds is getting that hardware. What's it going to take to get the appropriate hardware? You're going to have to also make decisions obviously about the hardware itself as well. What kind of hardware are you going to use? Next thing that we run to at Morantis is the biggest chunk of time is the network setup, the network environment, the network configuration. That will take up most likely 60 to 70% of your time getting everything set up properly to be able to have the open stack components communicate with each other properly. So that's really big. Don't discount how long that's going to take. That's going to take quite a while. And one of the challenges that happens there is that you've got communication between groups. So you've got to talk between your server group, for example, your network groups so you have to make sure that those are all there and those communication paths are open at the beginning. And then of course there's actually a configuration of the servers themselves. So you have to make sure you have time to actually go in there and make sure the BIOS is correct, the firmware, the hardware, configuration parameters are all set properly. So what are some ideas that you can do to prepare that? So one of the things you want to do is pre-plan, like I said, your hardware requirements. We've actually got a utility that's up on our website that lets you pick the right hardware for your open stack integration. Make your decisions about how you're going to do your deployment. Will it be highly available? Which means you'll need multiple controllers for your high availability. What kind of networking service do you want to use? Do you want to stay with Nova Network? Do you want to start using Neutron? If you do Neutron, do you want to do GRE or VLAN segmentation? So make all these decisions up front before you actually start doing your deployment. Figure out once you've got your hardware out there what each of those hardware items are going to be in terms of roles. Is it going to be a controller? Is it going to be a storage node? Is it will it be a standalone network node? Will it be a compute node? Make your choices ahead of time about what you're going to be doing there. Will a node be completely standalone? Will it be a combined role on that? So make those choices way in advance so you know exactly what you're deploying and how you're going to deploy it. Like I said, your networking decisions up front. So create your networking address plan, lay out your VLANs, lay out your network information, not only at the physical level and the network level but also at a logical level. So which VLANs are going to be used for communication for admin? Which networks are going to be used for storage? Which are going to be your public networks? Is there going to be a communication to the internet, et cetera? Plan all that out way ahead of time because that's going to save you a lot of time and effort having written it down and having that sheet available to you. Once you've got all that pre-installation work done, now you've got to do the deployment and here again you've got a whole bunch of choices. There's lots of deployment technologies that are out there. Some of them are more advanced than others, some of them allow more flexibility than others. So take a look at all the deployment options that are out there and look at your criteria for what you need out of a deployment technology and make those decisions before you actually go do the deployment itself. So here's some factors to consider in terms of deployment. So one of the first ones is, do you like working with CLI? Do you like working at the command line? Do you like kind of the OS level interaction? Or do you really prefer a UI? Do you prefer kind of a graphical user experience that guides you through the deployment of your OpenStack environment? So make that choice, that's a personal choice. As you pick the deployment technology, can you call somebody for help? Is the community or the environment around who created that deployment technology? Are they easily available, readily available to answer your questions? If there's something, I have a question about how to use the technology or even if there becomes an error or a bug or a defect in that technology, can somebody respond quickly to that need? So think about that when you're picking your deployment technology. Is it flexible? Can you make the deployment technology do what you want it to do or is it rigid? Will it only deploy in a certain way onto a particular configuration? Can you run it on your own hardware initially? So there are some deployment technologies that are linked to a particular hardware configuration, OS, hypervisor, all the way up to the guest OS and is that what you want in your deployment technology or do you need something that's more configurable, more extensible, more enhanceable for your business needs? How much automation do you require? Is this something that you're gonna be doing a thousand times or just twice? So how much automation needs to be part of this deployment technology? How much effort can you put into it in a manual process and how much can you be able to do this through an API or some sort of automated orchestration? Can you actually deploy multiple environments from the same utility? We find that again, customers and organizations are deploying multiple clouds into multiple data centers and you need to be able to have that capability in certain cases or it's all in one place, it's all one cloud and perhaps you can use something that's more silo oriented to be able to get your deployment in place. And then is the process easily repeatable? Can you do it again and again and again and be successful every time? So some things to think about in terms of deployment. So now you've actually got it deployed, now it's post deployment. So the cloud is up and running, did you deploy it successfully? Have you done run all the tests against it? Can it be used in real world environments? Tempest is excellent at just testing the APIs and making sure that things are running at a basic level, but perhaps you need something a bit more, perhaps you need something that runs real world use cases to be able to test the open stack environment under business workloads with the real world use cases for what your customers are actually going to use this for. So you're probably going to need a tool that does more advanced tests against high availability. Is your cloud resilience, is it going to survive in the case of a failure? What about all the platform services that are on your open stack environment? Because as we know, infrastructure isn't there just for infrastructure's sake, you need to have some sort of business workload on top of it, and that's where platform services come up, and you're going to need some sort of testing capability for those platform services. And then for the monitoring capabilities, so Solometer is incredible, it's excellent, but it's in its infancy, and it's certainly, it's growing, it's adding maturity, it's adding additional capabilities as it moves onwards. It's finally an integrated status in terms of Havana, but from a monitoring standpoint, you may need something more in your network to be able to get the information you need from your environment to make decisions around your business or your organization. So, for example, you may want to have something in terms of thresholding where as a value goes above a particular level, take a particular action, take an action against the open stack to change a parameter or to do a different orchestration, and when that happens, it leads you down the path of self-healing. And there are technologies and there are capabilities for monitoring tools that are out there that do this today, and obviously open stack as a community project will catch up with that, but something to consider if you're really putting business workloads into your open stack environment, you need something to be able to do that monitoring. And there's the ongoing operations, so the day-to-day care and feeding of your open stack environment. How do you add nodes to your open stack cloud? How do you remove nodes from your open stack cloud? I mean, one of the values of open stack is the elastic nature of the technology. So if you have workloads that have exceeded the capacity of your open stack cloud, you want to add additional nodes. How easy is it to do that? Make the decisions and make the ideas of how you're going to accomplish that as you move forward. There may be situations in your organization where you actually want to allow end users or developers to create their own clouds for short periods of time and be able to then tear those down. How automated is that process and how can you do that very easily and continuously within your organization? And then from a cloud operations standpoint, you've got the gathering information about the cloud itself. How big is my cloud? What kind of nodes are out there? What are the roles that are being done in those nodes? How's the performance that's going on? How are the configuration parameters that are in place? Is the cloud running as efficiently as possible? All those are things that your cloud operations team is going to have to do to be able to keep that cloud up and going. So think about that when you're thinking about deploying your second or X number of clouds, you're going to have to have an operations group that has those tools available to them and knows how to use them and take advantage of them. So again, the OpenStack cloud, the OpenStack train just keeps on rolling. I mean, there's release after release after release. And again, it's not just the major releases, it's also the maintenance releases, the bug fixes, security fixes. So is your organization set up to do CI CD, continuous integration, continuous deployment? Do you want to draw down from trunk every single time it's available and be able to integrate anything that you've got within there? Can you keep up with that six to eight week release process and bring down that code, be able to test it and get it out deployed every single time? And think about if you've got your own unique advancements or extensions you're doing to your environment, it's going to be geometric in terms of the amount of time it takes to be able to keep up with that. So because you have to download from the trunk, put in your fixes in there as well, then retest everything to make sure that not only do your fixes work properly, but you haven't broken anything in the community. So really something to think about, how much CI CD do you want to be able to do as an organization? Can you get on to patching? So again, patches, you know, the maintenance releases that come out. Patching is typically done through in-place patching, so it takes the resiliency of OpenStack into consideration. You can take down a service for a very short amount of time, patch it, typically patches will allow you for backwards compatibility, but something to think about in terms of the availability of your operation. Can you have a maintenance window to be able to make that change over if the patch requires some sort of loss of availability or bringing down of a service within OpenStack? Usually relatively painless, but something to consider if you're successful and you have an OpenStack environment that's out there, you're going to have to keep in mind, you're going to have to patch it very continuously. Then finally, upgrade, which is the big issue that comes up. Now at Mirantis we've found that probably the safest still methodology for doing upgrades is to create a parallel OpenStack. Now you don't have to use up the entire, you don't have to duplicate all the resources in your second cloud. You can steal some resources from your initial cloud, build your second cloud, and then start to migrate workloads over. We find that that's very successful, relatively low risk, and that leads to the best possibility of success. But something to think about, so when you create your first cloud, always leave a little bit of capacity available or know that your upgrade's coming up, you may have to add a little bit of capacity into your environment to be able to plan that second cloud, make that up and running, and be sure that you can do that upgrade successfully. Again, it doesn't have to be a major disruption in your environment. It could be a switchover relatively quickly, but it really is something that you need to consider to make sure your successful deployments continue forward. So just in summary, again, hopefully this got you some ideas to think about when you're moving on for your second and your additional closet are there. So again, the stressing, plan ahead of time. Don't just assume it's going to be an easy process. Go in there, plan the network, plan the hardware resources, plan the roles for your nodes, plan what you're going to do within the environment ahead of time. It will save you a lot of pain and anguish as you move forward. Make the right choice about your deployment utility. Pick one that fits your environment, that fits your organization, that fits your personality, shall we say, to be able to do the deployment in a way that you're comfortable with so that you can be successful in accomplishing it. Once you've actually done the deployment, make sure all the tools are available for monitoring, for ongoing operations, for be able to make sure that that cloud is working as efficiently as it can, and make sure that those are all available to your operations environment or operation resources to be able to be successful. And then once you've got the clouds up there and going, start thinking right away about how you're going to do patches, how you're going to do upgrades, how you're going to keep this project going forward at the right version level and may take advantage of the innovation that's out there in the community. It will really save you a lot of time in the future. So that's my presentation. Obviously I do represent Morantis, so I've got some resource information up here. We think that we solve a lot of these problems for you as a deployment and managing and operations technology from the Morantis OpenStack product that we sell. So I encourage you to go to our website, take a look at it, and we have a lot of resources and utilities that are there to be able to help you do a lot of the planning that I've talked about. So again, thank you for your time and I hope you have a great conference.