My name is Raghavan Srinivas, I go by rags and feel free to follow me at rags s, my goal is to have at least two people follow me after I finish speaking at a conference, hope I can hit that goal. So what I'm here to talk about is basically about OpenStack and kind of an evolving landscape and I work as a solutions architect at Ragspace. I really come more from an application background and somehow there is this misnomer that if you have an infrastructure as a service, your application is going to automatically scale and that's not really true. For those of you who have an application background, you know that your application has to kind of adapt to the infrastructure, your infrastructure has to kind of work with the application and so on. So the goal of this talk is not primarily to talk about OpenStack, I'll definitely talk about OpenStack, I will talk about what is OpenStack, why OpenStack and so on and why would you want to have your apps on OpenStack. But really the goal here is to talk about kind of this evolving application landscape as I call it and kind of the notion of amorphous clouds and I'll talk about all that in a bit. Before I get started, how many of you had never heard of OpenStack before we came to this conference?  So I don't need to talk too much about OpenStack, so what I'll do is kind of quickly go through it. I have a couple of demos, you know they've been kind of iffy depending on the time of the day, you know it's been working and it's not but you know that's typical how demos work, right? So those are real demos, you know they're working on my laptop, there is one that you know basically accesses the public cloud, there is another which accesses the private cloud.  So I will do a couple of demos but again you know if those don't work I will come back to death by PowerPoint anyway, okay. I work as an architect and evangelist, I've worked on several different technologies, but you know kind of working in the infrastructure side is a little bit new to me but like I said I think you know my goal is to kind of take my application skills and see how I can you know use that you know to kind of evangelize OpenStack in general and Rackspace private cloud you know which is where I work and talk about how it is going to be interesting to developers, okay. How many of you have you know already deployed an OpenStack so to say? A few, okay that's good. How many of you would call yourself as kind of developers versus system administrators you know? I mean I think it's you know the line is thinning but if you have written like thousand lines of code in Java or Python or Ruby or whatever your favorite language is as opposed to Bash, right. So would you call yourself more of a developer? How many developers, okay. How many of you would be system administrators who are never going to write any you know touch Java or anything, okay that's cool. So what I'm going to do is I'm going to definitely under emphasize J Clouds. You know J Clouds is the Java API for accessing you know any cloud really. You know it could be a public cloud, a private cloud, it could be Rackspace, it could be HP, it could be Red Hat really anything, right. But really it's one of the different APIs. You know we have Ruby APIs, we have Python APIs as well for accessing the cloud but what I'm going to talk about is you know is generally about application design and how OpenStack would help you in kind of you know building your application so to say. So here's my agenda you know pretty straightforward. I'm going to talk about scalability you know I think the goal of this session are really you know most of the sessions here is really about scale out, okay. We'll talk about you know tenets or pillars of a cloudy application, right. We will look at how OpenStack is going to help. Look briefly at J Clouds and somewhere in between I'm going to do a few demos, okay. And then we'll do a resources call for action summary. Seem okay, yeah, all right. So the changing application landscape, right. I wrote my application, right. And you know some celebrity tweeted and I have a problem now. You know everybody is accessing the application. You know where I expected about hundreds of thousands of users. Now I'm getting hundreds of millions of users. You know how do I, you know I have a problem, right. So how do I, how do I deal with this? The easiest way to deal with this is you know scale up, right. Get a bigger box, pay more money to Oracle, right. And be done, hopefully nobody from Oracle here, right. Okay, so you know application scales out, just add more servers and you're pretty much outside, right. But the problem with this approach is that you know as the database scales up, okay you really can't go beyond a certain point, okay. You get to a point where you hit the wall, right. You cannot keep scaling up and up and up, okay. And also there is a, another fundamental problem here is that you essentially will have to, you know, throw away existing servers, right. You know sometimes you just cannot keep going up on the existing box, right. You may have to get a new box, right. In which case it's not, you know, the ideal way to do things. So another way of looking at the same thing is, you know here's my infrastructure, right. And here's my application, right. So the easiest way, you know, to get more horse power and no pun intended here is to get a bigger horse, right. You know, very, very simple, you know, very easy to do that. You know, of course you can also make the jockey a little bit thinner, right.   You can make an application a little bit more lightweight and all that, right. But, but, you know, again, there is a limit. The point is that, you know, the point that this particular slide is trying to convey is that your infrastructure and application is kind of hand in hand, okay. I don't know if some of you have seen this movie, Avatar. You know, remember this, this character? Remember, you know, know the name Banshee, right? Is that correct? Basically, the application and the infrastructure was fused, right? Or in this case, the animal and the rider were fused in, right? It would be great if we had a Banshee, but unfortunately, you know, there are not too many Banshees in the world, right? So what you really want to do is you can have a hardware built for the worst case, but instead, what you can do is you can start off with a baseline capacity, right? And really what you do is instead of scaling up, you scale out, okay? So instead of vertical scaling, you do horizontal scaling, which is, which is kind of fundamental, you know, these are things that are pretty obvious, right? But from an application perspective, this is still somewhat, somewhat new, okay? So how do you, how do you kind of deal with, you know, unexpected loads or peak loads or, you know, loads that are fluctuating through the day or through the year or through the week? You know, essentially what you do is you start with a baseline capacity or routine capacity, and then if you want to quickly respond to unanticipated events, you know, something that you don't quite expect, you know, then what you do is you just add more Banshees there, and you're ready to go, right? So that's the idea behind horizontal scaling. So once you accept the fact, you know, that horizontal scaling is really the way to go with your applications, you know, things become a lot simpler, okay? I'm sure there are other ways of doing it or maybe there is another way of doing it, but I really don't know of any other way, you know, to be able to scale other than to use commodity servers, right? And being able to scale horizontally, you know, scaling up has its limitations. You know, that's really the bottom line of this particular slide.   But it's not the same with, you know, with the data tier, right? So it's, you know, when it comes to the data tier, now you have to all of a sudden kind of deal with it differently. You know, just putting more servers is not going to help you, right? Because your application also has to kind of adapt to that, right?  So in other words, you know, you want so many of these, you know, data to be handled by this server, this data to be handled by this server, this data to be handled by this server, and so on, right? The moment you start sharding, now you get into issues, right? You know, how do I deal with what happens if one of these fails? You know, what happens, you know, how do I replicate my key? How do I keep, you know, data consistent? You know, how do I keep my data, you know, resilient, and so on? So those are the kind of things that you're going to talk about here, but essentially the idea behind scaling is to be able to, you know, take this curve, right, you know, one of them is system cost, the other is the application response time, right? You know, which is really growing exponentially to somehow try to flatten it as much as possible. You know, that's really the goal of horizontal scaling, right? So once you have achieved horizontal scaling, you know, once you accept horizontal scaling, you know, of course, there are a number of other challenges you have to deal with, okay, but that's kind of the fundamental thing that you have to embrace, you know, before you can think of kind of scaling your application, okay? So let's say I've accepted horizontal scaling, right? But there are a number of other things that I really want to think about. Horizontal scaling, you know, perfect. But I want to be able to kind of autoscale, okay? These are all new features in OpenStack, okay? It's part of the HEAT project.  You can do that very easily. And to be able to do that, you know, based on certain triggers, you know, the trigger could be like, you know, how many number of users are there. It could be based on response time. It could be based on how many messages are in the queue, anything like that, right? And automatically the application scales, you know, in such a way that it's able to handle that load, okay? So autoscaling is one of those features. Design for failure, as somebody says, right, you know, if you design for failure, there is not going to be any failure, right? It's just kind of a cool thing, right? Rather than, you know, trying to prevent it, you know, just accept it and design for failure, okay?  Yagney, dry, and so on, you have heard of all this. Nothing new. It's all, you know, again about extreme programming. But in the case of a distributed application, right, which touches a number of different technologies, infrastructure, and so on, this is absolutely important, okay? As far as possible, use stateless services, okay? Stateless is great. You know, in fact, in OpenStack, lot of the services are stateless. Doesn't mean that there are no stateful services at all, okay? Since MySQL, okay, and we'll see that in a second, okay? Is a stateful service, okay? RabbitMQ, which is really the fundamental, you know, that's what's used for messaging, is also stateful. There are ways of dealing with stateless and stateful, but if you can, you know, try to stick to stateless, okay? Exploit parallelism. Just because there are multiple servers, okay? And if you're not really exploiting it, you know, it's not gonna help you. You know, yes, it may be good for redundancy, it may be good for failover, and so on, but at the same time, you know, if you can use those different machines, or those different servers, or those different compute nodes available for you, and use them well, you know, I think that's good. That's how we are exploiting parallelism, and there are a number of infrastructure, you know, that's kind of where I'm getting to, which kind of automatically do this. You don't have to do a whole lot, you know, to make it happen. So what you can do is, you know, kind of use that infrastructure, and kind of deploy it on top of OpenStack, okay? So hopefully I'm making the connection between this new generation applications and OpenStack, okay? Minimize data movement.  You know, ETL stands for extract, transform, and load, right? You can do, you know, ETL is good, but you want to minimize it as much as possible, right? One of the cool things about Hadoop, you know, which is the Hadoop distributed file system, is that it does not move the data to where the compute is. It moves the compute to where the data is. You know, that's kind of a cool thing, right? If you think about it. Because if you have like hundreds of nodes, you know, you don't want to move the data from each of those nodes, you know, to the compute because it's just a bottleneck, it's a huge bottleneck. So what it does, instead, is you have this MapReduce code which essentially runs on each of these different nodes, okay? Each of these different splits and so on, okay? Keep data closer to the end-user, you know, this is, again, if it's static data which does not need to be processed, you know, it's better to keep it closer to the end-user, where it's gonna be consumed. You know, it doesn't necessarily have to be a physical user. It could be a web service, it could be anything, right? It could even be an analytics engine. As far as possible, keep it closer to the end-user. The idea is to, again, minimize the data movement, okay? And one of the key things that I think is very critical, you know, is minimize barriers for exit, okay? So in other words, you know, if I have my application which is built on OpenStack with, you know, let's say a rack space private cloud, and for some reason you decide, well, you know, rack space private cloud is just not working for me, right? You know, you can move to HP cloud, you know, with relative ease, right?   And I know that, you know, you are designing applications and I really don't want to talk about all of those, but you know, real-time access could be a big thing, right? You know, if I'm doing everything on Hadoop, you know, Hadoop is really great for batch time processing, right? But not ideal if I'm using it as a operational store. In other words, if I want something right now, you know, it's probably not a data store that you'll use. You know, of course, there are some new initiatives happening at the Hadoop world, okay? That make it happen, but you want to think about real-time access, ability to connect to other data stores, you know, like analytics engines, you know, could be Informatica, could be, you know, whatever that is, right? Ability for business are non-technical users to visualize the data, right? So, you know, one of your user calls you up and says, well, I want to be able to visualize this data this way. You know, you're going to say, well, you know, well, I'll write the, you know, MapReduce code and get back to you in a couple of days. That's probably not a good answer, right? You want to be able to, you know, for them to write some queries, you know, whether it's pig, hive, whatever scripting language that may be involved. So some of the standard techniques, you know, that are used in, you know, whenever you do a scale out is kind of the shining. Distributing data over multiple nodes, okay? It seems very straightforward, right? I want to distribute data over multiple nodes. Replication. We assume that data failure is inherent, right? One of the nodes is possibly going to die, okay? There's a good chance at well, right? So how do I deal with this? So obviously, if I put it in, you know, the idea behind any kind of availability is that you really want to avoid any kind of single point of failure, right? So if you just have it on one node, you are in trouble already, right? So what you want to do is you want to be able to replicate this on multiple nodes. It could be one copy, it could be two copies, it could be three copy, or it could be 400 copies, depending on how far an idea you are. You know, typically, you know, one or two is good enough, okay? So resiliency is achieved via replication. Data resiliency is achieved via replication. But the moment, you know, you get into it, you get into all kinds of challenges, and we'll talk about all that in a second, okay? So one of the great techniques, you know, this came, this was introduced by Google, you know, basically it's the map-reduced technique, okay? And the idea behind the map-reduced technique is very straightforward. You have a set of mappers and you have a set of reducers, okay? So you take the problem and essentially, kind of break it down into a set of maps, which kind of looks like this, okay? So essentially, I have an input which says how do we use this map-reduced? There is a map phase, there is a reduce phase, dot, dot, dot, right? So each of these different nodes, each of these different mappers essentially gets a portion of the problem, okay? And essentially what it does is it produces some kind of a sort shuffle which looks like this. You know, it looks at Hadoop and says one, right? Map-reduced one, so it looks at the document that it is given and breaks it up into a map that essentially the reducer uses to combine those maps and produce an output something like this, okay? So there, A, the count is two, okay? I'm doing a simple word count, okay? Hadoop two, ease two, map one, map-reduced one, and so on and so forth, okay? So map-reduced is a great technique where essentially you kind of write a map-reduced program which essentially takes the input and kind of distributes it on different nodes, right? And solves the problem for you, okay? Does that make sense? Okay, it's again not something new, but has been used very successfully, not just in Hadoop, but actually in a number of other distributed systems. Message queues, and one of the things that you might have heard when you were designing systems is loose coupling, loose coupling, loose coupling, right? You really don't want to kind of pie two systems together. I think the easiest way to doing loose coupling is by using messages and queues, right? You know, it's very straightforward. You send something, and whoever is interested in looking at that will subscribe to that particular topic or queue or whatever, okay? And then take messages off it and process it, okay? In fact, there is a project called Project Marconi. Anybody heard of Project Marconi? Okay, it's an open stack. It's gonna be, it's actually an incubated project in an open stack, okay? And it's gonna be part of Project Havana, which is gonna be the next release of open stack. So the idea, hopefully I'm trying to convey is that open stack is becoming more and more developer friendly, which is really what open stack should be. The next wave of development should be driven by the developers, and hopefully all of us can contribute to that. So you might have heard of this as well, the CAP theorem. Whenever you have a distributed system, right? This CAP theorem kinda comes into the picture. It's also referred to as Breuer's Conjecture. Breuer was the one who stated this, and essentially, if you have three things which is consistency, availability, and partition tolerance, right? You can have only two things at the same time. You know, if you think of three things. So between CAP, between C, A, and P, you can either have C and A, or C and P, or A and P, okay? And really, it's up to you to pick which one you want. Most of the new, no-sequel databases and distributed systems that you're seeing today, there is a rapid proliferation, and you will see a chart of that in a second. Basically, have partition tolerance. So if you have more than one node, that means it has to be partition tolerant, to put it very simply, okay? So now, you have to pick whether it's gonna be consistent or it's got to be available, okay? And then you get degrees of consistency, like eventual consistency and so on, and then availability, right? Which means that it may not be available for a certain amount of time, which probably is okay for a lot of applications. Eventual consistency, again, probably okay for a lot of applications, okay? So from an application perspective, you know, I need to make this kind of decision as to which one I wanna use, okay? Can I live with consistent, you know, can I live with eventual consistency or can I live with the application not being available for a certain amount of time, okay? So here's an ecosystem, but the ecosystem is generally based on SQL, okay? And again, we are thinking mainly from the data tier, you know, scaling the web tier, scaling the other tiers are relatively straightforward. Scaling the data tier is a hard problem, okay? So if I have my data as relational, okay? Then there are a number of SQL approaches like, you know, like scale-based, parallelistic. There are a number of other companies, you know, which are essentially doing this, okay? There is a new SQL approach, okay? There is new SQL, which is not quite SQL. It is SQL, it's support SQL, but, you know, it's not the traditional SQL. And one of the examples there is NeurDB, okay? And there is a chart coming up, okay? Just hold on because, you know, it's pretty dense, okay? Then there is, of course, the no-SQL approach, okay? No-SQL approach is like, you know, MongoDB, CouchDB, Cassandra, and so on and so forth, okay? So those are examples there. And then, of course, there is Hadoop-based approach, which is kind of, you know, based on Hadoop, okay? And based on MapReduce, based on HDFS, and so on. There is HBase, what else can I think of?  But since I don't want to think about this, my friends at 451 Research came up with this chart. You know, it's a very interesting chart if you have the time, okay? I'm not gonna go through all of this, but essentially, it's kind of done like the London Tube Map, okay? So if you see, there are a number of different areas. Here's kind of the grid and cache zone. Here's kind of the relational zone. There is the non-relational zone, okay? And there are some which kind of go towards, you know, solar and so on and so forth, okay? But what is the bottom line here? The bottom line here is that there are just way too many choices, okay? As an application developer, you know, I'm sure you'll recognize, you know, something like, for example, you know, if I'm looking at, you know, whatever metascale is, okay? Or if I want to look at Oracle's NoSQL solution, it's somewhere out there, okay? MongoDB is somewhere here, right? Because it's in, you know, in one of those zones. As an application developer, you know, it becomes really, really hard, you know, to pick what you want to do. I was involved in a project very recently, and really, you know, you can't look at all of this. What we did was we kind of, you know, settle with a chart which looks something like this. So essentially we said, you know, what are the strengths and weaknesses of each of these different technologies, okay? These are just hard requirements, okay? The number of other software requirements, like, you know, do I like the company? Do I like their support? Are they 24 by seven and all that, okay? But, you know, in this particular case, if you look at, like, for example, Hadoop and HDFS, data locality is one of the big advantages, right? It has a very rich ecosystem, right? But the problem is it's kind of batch-oriented. You know, some of the newer initiatives for real-time are not really fully baked yet, okay? It's still happening as we speak. So those are the kind of things we have to live with, right? Cassandra and HBase, you know, it works really well with HDFS. There is really no data movement required at all, right? I don't know if any of you use data stack enterprise edition, you know, essentially what it does is, you know, it takes the same Hadoop data and you can repurpose that as a Cassandra node or a ring node and, you know, it uses HDFS to access the data. So it makes it very easy. But again, the problem with, you know, any kind of no-SQL approach is that there is no concept of a join, okay? So your data is not normalized, right? Which means, you know, the onus is on the developer, you know, to kind of keep the data consistent, right?  So if your asset is important, you are in trouble, right? So the point is, again, you know, as an application developer, there are a lot of things that you really want to be able to deal with. And my take on this is that there is really no silver bullet, right?  You know, all this is processed and we have an analytic compute grid. There, what we do is we use a number of different technologies, including mango, Cassandra, Hadoop and so on. And I think that's kind of how the enterprise is evolving as well. I put this up just to illustrate, you know, this is again something that I've seen in one of the, one of our customers. And essentially what they do is they do their Hadoop processing, you know, during the low time or the low time, okay? And essentially what they do is they repurpose the Cassandra nodes as Hadoop nodes, okay?  So now they're, you know, you have a limited number of Cassandra nodes, okay, probably only about two. The remaining 10 are now used for Hadoop, okay? So this is what I mean by kind of amorphous clouds. They're not really Cassandra nodes, but they're kind of evolving into, you know, what problem I'm trying to solve at the moment, okay? And then kind of evolving back and kind of shifting and, you know, and morphing and so on. And this reality, I mean, this is still, you know, not completely reality right now. I mean, it's not easy to do it. There are, you know, you have to do it with homegrown tools, but there are tools that are evolving to make this happen. And that is where kind of OpenStack comes in, okay? So what OpenStack does is basically, you know, it's an infrastructure, you know, for compute, for network, and for storage, okay? As simple as that. Okay, it's a virtualized infrastructure and we'll see this was, this is definitely not up to date. Okay, if you go to the OpenStack booth, you'll find the latest, you know, how many number of companies are participating, how many members are there, and so on and so forth. Okay, so just add yourself if you're not an OpenStack member yet, okay? But essentially, like I said, what OpenStack is, is a virtualized infrastructure for your compute, for your networking, and storage, okay? One of the things that, you know, kind of, it should have occurred to me earlier, but kind of, you know, as I was preparing for the talk, was that, you know, I thought about OpenStack, and I said, hmm, actually, OpenStack is itself a good example for how you wanna build a distributed application, okay? In fact, you know, the tenets of OpenStack are pretty well-enunciated, okay? And these are the OpenStack design tenets, you know, I'm not gonna read through all of this, but this I stole, you know, from the OpenStack, you know, website, as is, okay? And actually, if you look at how these, you know, components are designed, you know, these goals are really held to the very, you know, high order, okay? Scalability and elasticity, sorry, are our main goals, right? Any feature that is not a main goal is a non-goal, okay? So you gotta be able to kind of have the discipline. Everything should be as asynchronous, okay? If it's not asynchronous, then it's a non-goal, okay? All required components must be horizontally scalable, okay, needless to say, right?  You know, I talked about MapReduce. MapReduce is great when you're doing, you know, processing where those different tasks, you know, don't have any dependency on each other.  So if you have a shared nothing architecture, you know, it's good for distributed systems, right?  And again, accept eventual consistency and so on and so forth, okay? So the idea is that data storage, data centers are being virtualized, right? The idea behind OpenStack is just virtualized just about everything, right? You know, in fact, network is virtualized, storage is virtualized, and so on, okay? And we'll talk about what are all these different components in just a second, okay? But really the way I look at it is, you know, I come from the Java side and most of you probably come from the Linux side, right? OpenStack is really the Java EE for the cloud, okay? And think for a moment what this means, right? It's very easy for you to move from one cloud to another cloud, you know, if they're all based on OpenStack, and that's really the fundamental value proposition of OpenStack, okay? If you don't like rack space for every cloud, you know, no problem, go to the public cloud. If you don't like public cloud, you know, move to HP's cloud, or Red Hat cloud, or IBM cloud, or whatever, right? And that is kind of the same philosophy, you know, in which, which is why Java EE became popular as well. OpenStack session will not be complete if you don't talk about, you know, some of these projects, okay, Keystone, Horizon, Cinder, Swift, Quantum, Grants, and Nova, okay? Keystone is for identity management. Horizon is for, you know, it's basically a dashboard where you can spin up instances, look at, you know, the general health of your system, okay? Cinder is for block storage. Swift is object storage, okay? Networking is Quantum, okay? But the new name for that is Neutron, okay? Anybody heard of Neutron? Okay, so if you know Neutron, that means you're already up, okay, you already have. All right, I've achieved my goal today. Glance is for image management, and Nova is for computing, okay? So as simple as that. The bunch of releases that have happened, Austin, Bear, Cactus, Diablo, and so on, and as you can see, a lot of these projects gradually got added to these different releases. Havana is gonna have, you know, Grizzly had heat, you know, heat is not mentioned here, right? It's still an incubated project, but it's gonna be integrated or a core project in the next release, which is the Havana project, okay? Most, each of these releases are usually released, you know, just before a design summit, and those design summits happen every six months, okay? The next design summit actually is happening in November in Hong Kong, and the release that's gonna precede it is Havana, you know, which is coming out in October, okay? End of October.  You know, absolutely not. You know, there are some issues, but most often, you know, the community gets together and kind of hashes us out, and the big advantage is it's open and completely eliminates render block in, and really the idea is to be able to move between clouds. The architecture is pretty straightforward, you know, the first thing I'm gonna do is I'm gonna use what I refer to as the Keystone APIs, these are all REST-based APIs, okay, I'll talk about that in a second, and then what I do is I use the NOVA API to spin up an instance, okay, to create an instance, and all of the communication happens through RabbitMQ, okay, so it communicates with Cinder, with Quantum, Cinder is your block storage, Quantum is the networking, okay, and pretty straightforward, you know, architecture.  They're all REST-ful APIs, okay, and all APIs support some extensions as well, but you know, to use it is pretty straightforward, all that I do here, in this particular case, I provide rags as my username, and here's my password, right, and I'm gonna get back a token, okay, as simple as that, and that token is something that I'm gonna use, you know, to create a new flavor, or a new server, or whatever it is that I want to do here, okay, and that's pretty much it, okay, so what I'm gonna do here, you know, I'm gonna hope that my demo is gonna work, okay, and like I said before, I think OpenStack is a great example of how you want to distribute your application, okay, or how you want to keep your application distributed, and what I'm doing here, in this particular case, is I have two controllers as they refer to, okay, so what the controllers do is they handle all the infrastructure services, okay, like for example, RabbitMQ, Horizon, and so on, and so forth, okay, and then there are a bunch of compute nodes, in this case, I have three compute nodes, okay, and what they do is they allow you to spin up instances, that make sense? Now the beauty of this is that, you know, I have something called as HA proxy, you know, which basically makes this application highly available, okay, so essentially, I could do this with any application, you know, any user application, if I use the same principle, okay, so what I'll do is I'll show you how this is implemented, and if everything works, you will probably appreciate this, if it doesn't work, appreciate it anyway, okay, so here's my, if I look at Nova Service List, yeah, let me do that in a second, thank you, I thought I'd set this all up, but yeah, anyway, okay, can't see this, okay, for those of you who can't read that, you know, essentially I have a bunch of controllers, and I have a bunch of computes, okay, so what I'm gonna do here is I'm gonna go to my, okay, here's my instance, okay, and you'll see here that, you know, I'm using 197, okay, basically this is the IP I'm using, okay, to, you know, for Horizon, okay, and if I go back to my controller, okay, I will, let me see if I can blow this up a little bit, so if I do IP, you can see here that 197 is basically a virtual address, okay, which is pointing to that particular controller, okay, it's basically an address that kinda moves between the two different controllers, you know, depending on which controller is active or not, okay, so if a controller dies, then your applications should still work just fine, okay, that's the goal, okay, so what I'm gonna do here is, you know, launch an instance, okay, which is pretty straightforward, right, come on, okay, so I pick an image, okay, and I'm just gonna call it NOLA, okay, and call it tiny, whatever, shouldn't matter, and I'm just gonna launch it, okay, so hopefully at some point, you can see here that I'm, you know, it's basically doing a networking right now, okay, it's showing an instance name, it's spawning, okay, it got an IP address of <IP_ADDRESS>, you know, which is a VM instance, that is created on one of the compute nodes, I don't know which compute node it is, I don't really care, right, so it's active and it's running, no, right, which is fine, right, now what happens if my controller dies, right, so what I'll do to do that is, I will actually shut it down, okay, I will do a shutdown right now, okay, and hopefully what should happen now is the IP address, you know, the virtual IP should actually transfer over to the other node, okay, so what I'll do is I'll go to controller HA2, okay, come on, and we'll see if that works, okay, so if you notice the IP address here, you know, 197 was not bound to, you know, this particular node, okay, but if I run the command now, hopefully the virtual IP should have transferred over, okay, so do you see here it's 197, okay, so essentially it moved from one node to the other, so if I go back to launch my instance, you know, it should be as if, you know, that system never failed, right, it might work in a degraded mode, you know, because I'm not load balancing and all that, okay, but it's still working fine, right, so let me go back and see if I can launch that instance again, okay, so I'm launching that instance, okay, and really, you know, this is where I, I kind of hope that it'll work, okay, so if I go back here, you know, it should still be there, yeah, and at some point it should come up and be able to launch, okay, so, you know, I can still launch it, this is NOLA 2 after failure, after failure is good enough, okay, so it's gonna work in a potentially degraded mode, but it'll, you know, eventually spin up, okay, so if I go back to my controller HA2, right, and I just do a NOVA service list, okay, so which will list all the services, I should be able to see that those two are down, okay, you will see that some of those services are down, okay, you'll see, you know, do you see some of them being down, you know, whichever is on one is down, okay, and hopefully it finished launching, okay, so it aired out, but that's fine, okay, it aired out for whatever reason, but it should, you know, it should have spun it up and it's, so that doesn't make sense, you know, I think it's a great example, OpenStack itself, you know, of how to distribute an application and how to learn from it, so with that, let me talk about JClouds and I'm pretty much done, okay, your OpenStack comes in different, different, different flavors, okay, it could be a private cloud, it could be a public cloud, it could be HP, it could be Red Hat, it could be IBM, it could be Rackspace, it could be anything, right, to be able to use a common API just across OpenStack, you know, it's not easy, okay, and what we do at Rackspace is, you know, JClouds is just one example of what we support, you know, we have AppFog for Ruby developers, Pyrax for Python developers and so on, but the idea behind all of this is to be able to use a same API to access different flavors of OpenStack, okay, and there are different ways you can do that, there are portable APIs, there are ecosystem APIs and provider APIs, and what they do is they work for the ecosystem, they work for the provider and so on, so like for example, if I have a cloud files, you know, which is really a Rackspace public cloud implementation based on top of OpenStack, then you use the provider API, okay, and so on, okay, so you can use this for compute or for storage, okay, on Rackspace cloud servers and HP and Amazon as well, you know, if you prefer to use it, okay, just about, you know, a bunch of these different clouds, we have a bunch of different communities using this, you know, you might recognize Jenkins, you know, they use this for, you know, essentially deploying services, you know, Rackspace, of course we use it, Cloudbees, you know, Jenkins, they use it as well, Red Hat, you know, a whole bunch of companies are using this, it's a Apache incubating project and what it does is it essentially takes care of plumbing, re-authentication, pagination, and so on and so forth, okay, a number of those different features that you really don't have to worry about, okay, it is open source, it is community-based, it is all packaged, there are a number of, you know, examples and documentation, you know, that you can take a look at. So in conclusion, it's really a multi-cloud world, it's really a multi-technology world, right, and you want to be able to deal with it as an application developer.  So the application landscape is changing, okay, and the idea is to be able to leverage regular commodity servers, but as an application developer, you know, I have to do something different as well. It's really a hybrid cloud, right? It's really about multiple technologies.  OpenStack in general has a very rich ecosystem, you know, things are evolving. I'm not gonna say that, you know, we have conquered the developer's, you know, mind, you know, with OpenStack, I think we are far, far from it. Hopefully, you know, all of you can help in making this happen, okay? With that said, I think I probably have time for a couple of questions. You know, I have a few business cards here, you know, if anybody wants to look at how you can use Rackspace Private Cloud, you know, which is really what I get paid for, okay? Feel free to take a few business cards.  You know, hope you have a great conference and enjoy the rest of the time, and if there are any questions, I'm willing to take it now. Thank you again. Yes, yeah. So let me repeat your question and see if I understood that right. So your question was, you know, yeah, that's fine.  Something along those lines, correct? In this particular case, you know, this node is actually dedicated for that, you know, for that data center, if you will, right? So in this particular data center, I have two controller nodes, and that's typically what we recommend, and a lot of, you know, other open stack vendors also recommend the same thing.   You know, typically for up to about 100 nodes, you know, you're fine with about two controller nodes and the remaining compute nodes, okay?  Okay, and that's kind of how you go. I don't know if I answered your question. All right, thank you. Oh, okay. Yeah, so how do I exactly do that, is, you know, I can show you that. Yeah, we can take it up later, but let me show you really quickly for those of you who are, I think I just did this. So actually you can see here, basically I'm listing the knife environment, okay? And you'll see here that, you know, the glance registry and all that are configured for <IP_ADDRESS>.197, okay? So that was the IP that I used, okay? So essentially using the knife scripts, you know, I kind of say, okay, this is gonna be 197. So controller HA1, the two controllers are gonna be, you know, if this goes down, the other one is gonna be, you know, grabbing back and so on, okay? So it's all done using knife scripts. I don't know if that, again, answered your question, but let's move on to the next one, yeah? Yeah, yes. Yeah, v, ea, v, how do I put this?  One of the things, actually, Gazang, I don't know if you've heard of that, they are actually doing a talk in this conference. I recommend you go to that talk because we use them in conjunction with another solution that actually we provided for the help, IT provider, okay? So, sure, no, nothing built in yet, but there are a number of other providers that work with OpenStack. Or does anybody have anything to add? Or, you know, I may not be aware of everything, so feel free to jump in if it's, you had a comment, or? Now, I think what he's talking about is data which is not in flight, but data which is resident on the desk, right? Both, both. Any other questions? Thank you. Thank you. Thank you. Thank you.


What's up everybody welcome to SPM buzz. I am right here at the Radisson blue for the season two of a chalo culture lunch and I am dealing with some beautiful ladies. Hi ladies. Hi. Alright guys as you come in those are the ladies that are going to be ushering the guys in and today we are at the chalo culture blue and guys we can't wait to talk to the three sisters that is entrepreneurial Betty chalo sister Masi chalo and of course their last born Gloria chalo guys we are so excited to be talking to the three sisters and just to hear how was season one for them and what are we expecting from a season two so all you have to do is stay tuned on SPM buzz as we are going to be keeping you posted on everything that is going on on this launch my good name is Miss Kitingi stay tuned on SPM