 Okay, the mic's working. Yeah, sounds like it. Welcome to the, I think, last but one session of the OpenStack Summit. The fact that you're here means you're really committed to learning about Delta Cloud. Thanks for coming. My name is David Ludacard. I'm an engineer in RedHead's cloud engineering group. And I also maintain Apache Delta Cloud, which is what I'm going to be talking about here. I also participate in the working group that's the CME standard. And I'll talk a bit more about that too. Kind of the overarching thing I want to get input on and some thoughts on is how we can foster more collaboration between OpenStack and Delta Cloud and whether there's interest from the OpenStack side to go deeper into interconnecting the two. So my talk, I'll talk about cloud APIs in general, just what the general landscape is a little bit. Then I'll talk about what Apache Delta Cloud does and what it's for and what it's solving. I'll explain what CME is. I'll say a few words about the EC2 frontend we have. I don't think I need to say very much about EC2 since I assume that pretty much everybody's familiar with what it is and how it works, at least at a high level. And then I'll talk a little bit about how to use Delta Cloud with OpenStack. So cloud APIs, it's one of my colleagues likes to say it's a total Goad rodeo out there. Cloud APIs are the way that every vendor tries to lock their users into their specific solution because if you use anybody's cloud, sooner or later you'll have so many tools, so many assumptions in your usage of that cloud that moving from one cloud to another is very difficult. And even if lock-in wasn't a big problem, just the differences between the APIs are in a lot of cases big enough that you have to do a lot of gymnastics to adapt whatever management or tooling you do against the cloud from one cloud to another. And these cloud APIs, some of them have material differences, there's differences in features, one cloud lets you build private networks and VPNs and whatnot and others don't. But then there's also a lot of what I like to call annoying innovation where the same thing is done in slightly different ways, which is just a headache to code against. And those two buckets we try to kind of make you forget with Delta Cloud. And the situation kind of screams for a standard for something that everybody agrees on they can use. There's two kind of standards. I think from an OpenStack point of view, everybody's very comfortable with the idea of a de-factor standard. I mean OpenStack is clearly trying to establish itself as a de-factor standard. And I would view it as one of the two likely candidates of de-factor standard in the industry. The other one, of course, is EC2. Even though coming here to the summit, every time it doubles in size and it's gigantically big and I'm always floored by how much interest there is around OpenStack, it's easy to forget that the cloud world is much bigger than OpenStack and there's a lot of things going on and a lot of players that aren't OpenStack. EC2 has all kinds of problems even as a de-factor standard from a technical point of view from all kinds of other things. There is, though, also demand de-factor standards. And me as an open source guy, that's like what I feel really comfortable with, the de-factor standard. We have an implementation. Everybody writes to its API and that's great. Everybody's gonna be happy. But there are situations where de-factor standard isn't good enough. For example, if government entities want to put certain solutions in RFPs, they can just say, oh, make it look like OpenStack or some other implementation. They have to actually cite something that isn't a recognized standard that NIST or ISO or somebody has actually given their stamp of approval to. And in the CME working group, we actually have a bunch of telecoms and they are very, very keen on having a standard for exactly that reason so that they can go to vendors and say, build me something that works with a spec here. There's an open source community. The challenges or generally the challenges around standards are that for it to be accepted, you really need both. You need a de-factor standard that's also de-jure standard. A standard that isn't a de-factor standard that sits on the shelf and noise the hell out of people. And we know from the open source experience there's really only one good way to build software and that's the open source way. We know that the tight cycles and the feedback from users into implementations all that has all kinds of good benefits for the software that comes out of it. But open source is not enough because there are proprietary players who will never jump on open source solutions. Especially in the cloud space, I'm sure everybody can think of at least one of the players that will be very hesitant to jump in. And for a standard to be really good, more from a technical point of view, it has to be adaptable. You have to be able to offer that API, for example, in front of lots of variations of the same cloud. Kind of like when you deploy OpenStack, you deploy Cinder, you deploy Quantum with it. If you don't, users of your installation should be able to find out what's there and what they can rely on. So that's kind of the big picture around this whole API discussion. For Delta Cloud, we started Delta Cloud a long, long time ago towards the end of 2009. The reason we started is we looked at what was happening in the cloud landscape at that point, and we saw that there was a gigantic potential for lock-in, and we didn't want our users and for the whole industry, really, for this lock-in to happen. So if you notice, this predates OpenStack, actually, Delta Cloud, so there was no OpenStack when we started it. And in talking to people around Delta Cloud, partners, customers, whatever, users, it became clear that they looked, since Delta Cloud was a redhead project, they looked at it as not so different from APIs that any vendor will offer. They're like, it's just a variation of the same problem. And to address that, we took Delta Cloud in 2010, I think we took it to the Apache Incubator and made an Apache project just so it's clear it's not a redhead thing, it's not redhead-owned. Apache has all these processes around who owns what and how you get involved and who gets a say and all those things. So by going to the Apache Software Foundation, we cleared all that up and we've been a top-level project at Apache since October 2011. So like a year and a half, though. Okay, architecturally, it took a while. I mean, it took like a year or so, I think. I think at the time, the Incubator was just very slow-moving and, yeah. Because we were an open-source project before, so a lot of the things that the Incubator supposed to do, like teach you how to do, how to work as an open-source community, we already knew. There was, the one really useful thing about the Incubator was the Apache Software Foundation is super anal about anything to do with IP to make sure that all your ISDOT and T's across about copyright and licensing and where code came from. And that really made a difference in just cleanliness of documenting. Because we had a few places where we just copied and pasted some code in documenting where that came from. And I think today, the ASF has cleaned up the whole incubation process and I think it's much faster now for projects to move through there than at the time we did it. And I mean, we also took part of the reason why we were in incubation so long as we also took it as an opportunity to kind of experiment with our APIs and break compatibility and took, radiating as the point where it said, this is stable now, we're not going to break APIs in a backwards incompatible way anymore. I mean, the breakage was very minor, but there was still some in the course. So when we started, we just had what I now call the classic Delta Cloud API. Yeah, this is like a architecture diagram you could say of Delta Cloud. So Delta Cloud is a RESTful API. It's different in that from the various cross-cloud libraries you might know, like J Cloud, Fog, Bodo, whatnot. So when you run Delta Cloud, you run a server and it exposes one or more RESTful or web APIs, let's call it that. So we have three front ends that are kind of responsible for taking in requests and turning them into internal objects and there's a little bit of core functionality and then for each of the clouds we talked to, we have a driver. So we have an EC2 driver and an OpenStack driver and an Overt driver and what have you. When we started Delta Cloud, we only had the classic, what I now call the classic Delta Cloud API, which we were building in kind of the bottom up open source manner. We started with like the simplest possible thing that could work just enough to let you launch instances and stop them and then over time we added a lot more functionality to have a pretty complete coverage of what an IAS API does. And then we got, we were doing that for about a year and then Redhead got involved with the DMTF, the Distributed Management Task Force who was working on the standard CME. I'll talk more in detail what that is in a minute. And so we added a second front and the CME front and kind of as for us a proof of concept and get a feel for what the standard really does and where it works well and where it doesn't. And then the third one happened really last year at the OpenStack Summit. There was a project that was writing an alternative EC2 front and for OpenStack called Awesome, I think. And we looked at that and we're like, you could do this much, much more easily with Delta Cloud because all the plumbing's in place already, it's really just about how you expose the internal plumbing in the API to make it an EC2 compatible front and so we added that. And for example, our Overt or RevM which is Redhead's word management solution now uses Delta Cloud to give people kind of a lightweight cloud. Like you run Delta Cloud in front of RevM and you can talk to it as if it were a cloud and use one of these three APIs, including EC2. So the drivers is really what makes Delta Cloud useful and here's kind of a list or a picture of most of them. The ones, the clouds we support in the back end of course OpenStack's there. Fujitsu has their own cloud and they've actually been very, very active in making sure that their cloud is supported. As I said, you can use Delta Cloud also to turn word management software into a cloud as a cloud front end and we do that for vSphere and for Overt for this RevM thing. And IBM has also been active in helping us out implementing that. So that's kind of the high level overview of Delta Cloud. No, I think we've got time. Yeah, yeah. So what we do is in the classic Delta Cloud interface we actually advertise in the entry point when you first come to the server, we advertise variations. Like some clouds don't let you inject user data into instances when you launch them. So we tell you whether that's there or not. So when you go to launch an instance, you know what to do or the client can throw up their hands in the air and say, hey, I really need these particular features. Yeah, yeah, yeah. I mean, we don't have, we don't have any Q and functionality in Delta Cloud yet. Like, yeah, but I mean, if you, for example, if you, as I said in the beginning, if you deploy OpenStack without Cinder, without a volume block storage, you'll just not see certain things in the API that talk about block storage. Or if you don't have a Swift, we have functionality for the block bucket storage type stuff. If you don't have Swift, they won't show up and you can't really get to them. Okay, see me. It's done, as I said, by the Distributed Management Task Force. The thing that makes this very different from kind of OpenStack is that it's very industry heavy, very vendor heavy, but it has a very broad participation across anybody who's got an interest in cloud, like Oracle's there and VMware's there and Microsoft and IBM and you name them. If you don't know the DMTF, they're also famous for things like OVF, this format of encapsulating virtual machines and moving them around. And something called SIM, which is like a very low level standard, which is the backbone for I think stuff like Dash and Smash and SMBios, these are all DMTF things. And when we worked on the standard, we kind of started looking at what's out there, what do people have in terms of APIs and try to come up with enough functionalities to cover most of what people do. Took a pretty long time, took almost two years to do from the first meetings to actually publish the standard. It version 1.0 was published last summer in August. It is a restful API and it's completely from the ground up. If you've seen SIM before, CME has 75% of the name, the same as CME, but nothing else. Like it's completely disconnected from that. One of the things we were very careful in the classic Delta Cloud API was to really just make it a translation layer so that we wouldn't have to keep state. With CME that's possible and you have to run a database when you run Delta Cloud with a CME front and there's certain things in the standard that just force us to keep some data. Yeah, it's not great, but it's also not a big deal. Okay, so the model for CME is really if you've seen a restful API, there's very few surprises there. The only thing you need to know to go to the server, which in this case would be a Delta Cloud server running, is the URL of the entry point and from there you can get to everything else. There's several buckets of functionality which are underneath here, systems, machines, volumes, networks. There's another big bucket around events, monitoring and all that. But in terms of implementation, what Delta Cloud does, we have very good coverage on the machines servers in OpenStackSpeak, very good coverage on the block store side. We're working on the networking side. CME has a very rich networking model which looks surprisingly familiar to anybody who knows Quantum because they were actually done by the same people really. But yeah, we're working on that, getting networking in there. And then the last thing is systems which is a way to manage a whole bunch of resources as one thing, so you can say, I want these networks and these instances based on these images and these volumes and bundled it all up and control it as one unit. Yeah, so CME because we approach it from the point of view of it has to be, for the provider, it has to be very flexible what they support and what they don't support. Pretty much anything in CME is optional. If you look at the standard, don't be discouraged, it's a pretty big document, like 200 pages, but it's enough, most of it is more like a reference. So if you read the first 10 pages, you're pretty much good to go and then you can look up the things you're interested in. There's also Prima, if you wanna read about it, I would start with a Prima. Yeah, and it's very regular. There's, for discoverability, there's this notion of metadata so you can indicate whether, when you create a machine, you can inject user data or whether machines, when they first come up, whether they're stopped or started, those things are all discoverable so that clients can adapt to those variations. Just as a little, I know API demos are really exciting, but just to give you a better feel, this is... I can do it. Yeah, this is an excerpt of what you get when you go to that cloud entry point. The more important things are kinda at the bottom, it gives you pointers to where the machines are and volumes and all that and then when you go to that URL, it will actually tell you what URL to go to to create a machine, for example, and lists all the machines with pointers to details about each machine. So it's using the standard restful Hadoz pattern. There's a little bit of metadata there, like the driver and provider, that's really a delta cloud thing because you can use the same delta cloud server to talk to many different clouds. You just send a couple headers. You send a header that says which driver you want. I want the EC2 driver for this request. I want the vSphere driver for this request and then there's a concept called a provider, which is really the URL of the endpoint. Then if you say, I want to talk to vSphere and your driver header, you also have to supply the URL where the vSphere is running or if you say open stack, you have to provide the URL of the keystone for that open stack. And then here's just, even though the standard is pretty big, actually doing something with it is pretty straightforward. So this is the simplest way how you can create a machine. You just post a bunch of JSON to the server and the individual things is a machine config is what opens stack calls a flavor. It says I want this much RAM, these many CPUs. Machine image is the image that you want to boot the server off and then you can also specify credentials, which in CME are their own object and the SSH keys get put in that go with these credentials get put into the machine somehow. And what you get back underneath the line is the response which is just the location of the URL for the new machine you just created. And then you can go there and see what state it's in and when it's done. I mean, it's no surprise, I think for anybody who's ever seen the Nova API. What we Delta Cloud specifically I do in around CME is a number of things. There's the CME front end, which lets you use Delta Cloud as a CME provider server. We have for the classic Delta Cloud API we had the API would respond to JSON and XML, but we also had an HTML. We also do HTML requests, which was really nice for people to kind of explore the API and just click around because it's a little nice and then staring at XML or JSON for CME because the standard says it's only JSON and XML. We actually moved that into a separate little web app that talks to a CME server and then just shows you your machines and whatnot in a slightly nicer way. That the whole point of this web app is more as something to help you explore the API. It's not meant as like a full application that does much more than the API itself. Yeah, that web app is actually a normal web app. It has forms and buttons that you click on. And then there's also a little test suite that you can use to, if somebody claims it's that they have a CME endpoint, you can use the test suite to at least reassure yourself that that's really, that really has kind of the functionality that a CME thing should have. And one of the things we're working on is the server itself actually has in it a big part of what you would want for Ruby client. And we did some work to make it possible to pull it out. There's a little more work needed, but then we'll also give you a Ruby client that you can use to talk to any CME server, be it Delta Cloud or anything else. Okay, that was it for what I wanted to say about CME specifically. The easy to front end, as I said, it started as a proof of concept on the log just to see how easy it is to put another API in front of Delta Cloud. RevM uses it now as their easy to front end. It's the functionality is still kind of basic. It kind of gives you enough to the life cycle management and launch instances. You can manage SSH keys. There's a lot more things that couldn't should be done. A lot of things that would actually be supported by the Delta Cloud core and the drivers that we haven't really exposed in that easy to front end. But it's there and if there's interest, we can easily expand it. I was amazed by how quickly that easy to front end came together. It was like a week or so. So it's really easy to expose what's there already with a query API. Okay, so specifically for OpenStack, what does Delta Cloud support? What kind of things can it do? So for Nova, we have pretty complete coverage of kind of the Nova functionality. You can talk about flavors and regions and images servers. Swift is pretty much all there too. We have block storage, block bucket type storage, object storage in the classic Delta Cloud API and use Swift for that. Cinder is there, Glance. So those things we have the big, the biggest hole obviously is Quantum that we're working on, as I said. But yeah, you can do a lot with Delta Cloud against running against OpenStack. In terms of how to use it, it's a little web server that you bring up just because normally the client would talk to some OpenStack installation and now you're putting Delta Cloud in the middle just in terms of network topology, you want the Delta Cloud server either to run close to the client if you're running an application or close to the native API endpoint. And I mean, if you're deploying OpenStack, that's what I would do is run it together with your API endpoints for Nova and Keystone and whatnot just to avoid additional network overhead. And yeah, I mean, running it is very uneventful. You install it, you tell it where Keystone is and that's pretty much it. Oh, as I said, the server is stateless, which also means we don't store any credentials. We don't do any account multiplexing or anything. What you do is when you make requests, we use basic HTTP authentication and so you send us a user name password where the user name also has to contain your tenant or project for OpenStack. But you just do that with every request and there's no worries about somebody breaking into Delta Cloud and stealing credentials. No. Actually, the Keystone token, I think we do for a while. Yeah, yeah, yeah, yeah, because OpenStack, you have this two-step thing, right, where you first have to go to Keystone. So yeah, yeah, for that, I think we do that. There's, I mean, if you run the CME front and you have to have a database for, sorry? Well, if you only run like the classic Delta Cloud front, then no, there's no database when you talk to OpenStack or EC2. Okay, if you want to learn more about Delta Cloud, this is where the project pages are, where you can find docs and how to install it and where to get the code and all that good stuff. And we also hang out on Pound Delta Cloud on FreeNode if you have questions, need to find help. Okay. I mean, since we worried about that recently, like the networking models are a little differently, different, like Quantum has the notion of a port which kind of lives on its own, whereas EC2 has network interfaces which have to be attached to a machine. Those are kind of model differences. I mean, it's mostly like small details. It's either big functionality that's missing or like small details like this port versus NIC kind of thing. In terms of, are you specifically asking like where OpenStack has to catch up with EC2? Yeah, I think there that the biggest one isn't so much in the, the biggest difference isn't so much in like the core services, storage, compute and all that. The biggest difference is in all the stuff that EC2 offers beyond that, like queuing, whatever, mail, hosted databases, all those things which are another point of where you lock yourself into a cloud, right? And it would be for OpenStack just by itself really interesting to work on some of these services. I mean, there's some talk about more network oriented services like load balancers, VPNs and all that, but I don't know if there's much work around queuing and those things. Yes, I was so waiting whether anybody would ask that question. Yeah, I don't think it would be a huge issue to put an OpenStack front and so you can talk OpenStack to EC2. Yeah, oh yeah, I should have mentioned that the heat guys are actually using Delta Cloud to have heat talk to different clouds. So what they're doing is they have, kind of in their back end, they have, they started with code that just talks to the OpenStack API and they're implementing a second kind of back end that talks Delta Cloud so that you can run heat against vSphere, for example, or some of the smaller clouds that I had up there. Yeah. Yeah. It's Ruby, it's written in Ruby and we use a little framework called Sinatra. Yes, it's, I mean, we have patches for it that are, I think, pretty much ready to be committed so that you have at least the beginnings of quantum functionality like live network, so you can create networks and delete them. You can attach, yeah, you can create ports, attach them to machines and all that. And that's a matter of little code review, I think, if they haven't, I haven't really looked at the code this week, but it's imminent. Any more questions? Yeah, uh-huh. You wanna talk to this man there. Okay, well, thanks for your interest and enjoy the rest of the summit, another hour or so. Thank you.