Adventures with CloudStack and OpenDaylight
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Trippaers, Hugo
I've been involved with CloudStack as a project management committee member and I have been focusing mainly on the software defined networking implementations. When the OpenDaylight project started to become more popular integration between OpenDaylight and CloudStack was soon something on my wish list. This talk is about my journey to get support of OpenDaylight into the CloudStack project. This talk is partially about the technical implementation is getting the code bases to work together, but also on how ideas on implementation needs to be aligned between project for any interoperation to become a success. The intended audience for this talk is developers who are interested in software defined networking or who are interested in hearing about some of the cross project hurdles one might have to cross when doing an integration. This talk will be discussion on the lessons learned from driving an integration between two Open Source projects, OpenDaylight and CloudStack. The topics touched are the technical integration details on how both project think about networking and how this is aligned to allow for interoperation. The following topics will be covered in the talk: * Networking model in CloudStack * Networking models in OpenDaylight * Integration issues, where are the brains at * Integration issues, a CloudStack fanboy in an OpenStack crowd * Integration issues, release pressure versus doing-things-right * Current status of the integrations work * The way forward Technical depth of the talk will be all the way down to the OVSDB integration and implementation details of OpenDaylights modules structure. Mixed with a piece of my mind on how the communities reacted to this integration process.
 OK, I just got a thumbs up so we can get this show on the road. Everybody still awake? Hello? Wow! This is pretty awesome for FOSDEM that everybody is still awake. I hope you like it. I chose a black background, so nobody has to look at really bright colors. I tried to keep the images a bit low, so everybody who has a hangover like me should be pretty much OK with the presentation. This presentation is an adventure story, and so I chose this image to kick it off. It's an adventure story about how I got involved with Apache Cloudstech. It comes to get most of that part, but especially... Five minutes early. Yeah, he gave the thumbs up, so he said, get started. You want to wait? Yeah. So even though we're five minutes early, we get started anyway. You know any jokes? No, actually not. I'm a dead serious guy. I don't do jokes. Sorry. So, who am I? Well, I'm Hugo. Working as a mission-critical engineer for Sjubak Filles back in the Netherlands. I'm also part of the project management committee of Apache Cloudstech. Contributors open daylight, especially on the OBSDB part, which I will be telling about today. And actually, if I have some spare time, I try to spend it behind one of my playstations. Though, unlucky for me, I don't have that much time for it nowadays, since I'm working on all those projects. If you want to reach me for some reason, there's a lot of contact details over there. Please try not to tweet too much during the presentation, otherwise my pocket will keep on buzzing. So, what I want to do today is tell a bit how I got involved with the Open Daylight project. Open Daylight is a project. There's a lot of noise going about Open Daylight. And, yeah, I decided to have a look at what it is, what can be used for, and especially since I'm working with the Apache Cloudstech project as well, and my main focus within Apache Cloudstech is software-defined networking. Open Daylight for me was really interesting to look into. So, I'm going to tell you a little bit of background about Apache Cloudstech, a little bit of background about Open Daylight. I'm going to ask a question that everybody should be asking in this room, why the hell would you want to integrate those two projects? And I'm going to tell a bit about my adventure stories. And the adventure part here is what actually happens if you decide to take a step and integrate two projects. So, Apache Cloudstech. Apache Cloudstech is an IAS. It's a cloud management system. It orchestrates your hypervices, it orchestrates your networking, and it orchestrates your storage. It's a mainly Java-based project. It's been around for quite a long time. Though it gained the most momentum actually when it joined the Apache Software Foundation, but it has been existing for quite a while before that. We currently on our, yeah, on the release 4.3, or close to releasing 4.3, pretty stable platform, a lot of enterprises actually using it, we get a lot of positive feedback both from open source communities, but also from commercial parties who are building businesses around Cloudstech. So, it's really gaining a lot of momentum. And one of the things I like about the Apache Cloudstech bit of software is that, yeah, it supports a multitude of different hypervices, networking platforms, etc. Here's some of the networking platforms that we support. We support NTP, we support Midokora, we support Stratosphere, Big Switch. The unlucky part for a lot of people is that most of these offerings are actually commercial offerings. So, hence I'm really glad I can actually be here and talk about integrating an open source software-defined networking platform. And that's this one. That's Open Daylight. Well, actually Open Daylight is a lot more. Open Daylight is quite a big project. There's a lot of big vendors and a lot of enthusiastic volunteers working on the project. And it's really, it's more about facilitating the community. It's about providing a stable, available controller platform that can support a variety of software-defined networking tools, but also network function virtualization. It literally does a lot. I listed a few of the things that I found, but, yeah, there was a session earlier yesterday about application archeology. I think that's suited this, really dive into it and see what it all supports. It's almost impossible to keep up. Everything okay? Seems to be tech, no problem? Just on the screen. Okay. So, the things I've been looking at is mainly at the network virtualization part, and then you hit stuff like OpenFlow, you hit stuff like OVSDB, virtual tenant network, OpenDov, PEDTES, yeah, they're support for the board, support hardware, it supports software switches, really a lot of things. So, when I found Open Daylight and started looking into the project, I said, okay, there's some serious potential here. It has the possibility of working with an open community, working with an open source software, basically get my needs for Apache Cloud Stack and have them with an open project. So, that was actually the tricky part. So, what is it exactly that I need? So, then, yeah, looking at the Apache Cloud Stack networking setup, it's the basic of what we do with the networking part of Apache Cloud Stack. We're like, okay, so, what do we have in Apache Cloud Stack? So, we have basic networking. Basic networking is, well, basically the old Amazon-style networking, everything on a big, flat IP network, isolated using security groups and some foo-doo that deals with filtering MAC addresses, et cetera, to make sure you have some kind of tenant isolation. Then there's the advanced networking. It's actually, well, not even as advanced, but that's how it's called at the moment. But the advanced network, the difference here is that it is layer two separation. So, it's really, you get your own private broadcast domain and actually we're using, yeah, I think nowadays it's called network function virtualization. We use a router construct that deals with all the stuff, like routing, firewalling, low balancing, et cetera. And it sits between your network and the outside world and allows you to make use of its services and also give you some privacy on your own network. We support Virtual Private Cloud, which is actually a, yeah, it's almost the same as an isolated network, except it's a multi-tiered network. And for me, the advanced networking is really the most interesting bit. I'm the company I work for. We actually, we're users of CloudStack. We're not selling any products based on CloudStack. We're not involved in the community. We're not selling hardware. Anything, we're just users of CloudStack. For us, it's really... Speed up. Okay. So, is this better? Yeah. Okay, sorry about that. Let me repeat. We really need the basics about networking because it's actually the most important part that we will be talking about for the rest of the presentation. So, there's basic networking, separation based on L3, and there's advanced networking with separation based on layer two, individual broadcast domains. And as I was saying, I'm really a user of CloudStack. We use it to, inside our company for a lot of different purposes. And for me, the advanced networking is really the interesting thing. We have a lot of networks. We have a lot of time, a lot of minutes, and VLANs just didn't cut it anymore for us. So, quite a while back, we actually switched to using software-defined networking. And software-defined networking really fits with the advanced networking model where we can create isolated broadcast domains on any kind of infrastructure without having to rely on switches doing a lot of the VLAN work, going into the switches, configuring them. So, we're really a fanatic user about software-defined networking. So, we were already using it, and I was working with the NISTERA MVP mostly, and then I found the Open Daylight project. With my hat on as Apache Project Management member committee, it was an easy decision. We need to do something with Open Daylight. It's a fantastic project. A lot of nice people over there. It's supporting just about anything you can find in a networking stack at the moment that's open and available. And, well, as Apache CloudStack, we're a cloud management system where, basically, an orchestrating party. If there's nothing we can orchestrate with, we are a pretty useless project. So, orchestrating with Open Daylight means for us that we can actually be part of a bigger, we can expand our ecosystem, we can expand our usability for our users. So, it's really a good match, and, yeah, it's an open project, so that was great. And one of the other big reasons is that there was a lot of talk about should we be doing something with SDN. Of course, we had support for software-defined networking vendors already in CloudStack, but, yeah, you want some open solution, you want somebody, people can just download, use, and build software-defined networking with in CloudStack. So, we already have some support. We have support for VXLAM, we have support for GRE. So, basically, we're already acting like a bit of a controller, but there's people, actually, more knowledgeable about building controllers. We are really good at orchestrating stuff, and maybe we should leave the networking controller a bit to actually all the projects who have the networking people and know how and the technologies that actually do it. And Open Daylight is one such project. They really have the knowledgeable people about software-defined networking, so we can leverage those, yeah, those great minds and get our stuff for free. And, of course, as everybody here knows, it's actually quite fun to do such a project. So, this one for me, the fun started. So, I already found Open Daylight, I was getting involved, and I was like, okay, now I have a project with about 20 sub-projects. What the hell am I going to support here? So, it was really time to sit down and say, okay, what is actually that I want to do? I can just about integrate anything from Open Daylight, but what's actually useful from a user perspective, what's useful for me to do as a first step in the integration part. So, I said, okay, my goal is going to be, I want to have a couple of KVM hyperfixes, I want to be able to build an overlay network between those hyperfixes. Really, the bare bones about what it is that virtual networking provides you, overlay networking provides for you. So, I decided, okay, that's going to be pretty easy, so it's on to the API. That's actually going to be a really tricky bit, but I'll explain that later. Because then we found the next problem. Yeah. What the... I mean, okay, I said I want KVM support, I want to build an overlay network. There's actually quite a few projects providing overlay networking in Open Daylight. There's virtual tenant networking, there's Open Dove, and there's the Open OVSDB plugin that works together with the OpenFlow plugin. For me, I selected the OVSDB and OpenFlow plugin, mainly because this stuff I'm familiar with. I'm already used to working with OVSDB, I'm used to working with OpenFlow. So, for me, it was something I could understand it, I could work with it. And, at the time, it seemed pretty easy to get into. How wrong I was, because it was nowhere near finished. I mean, we're currently just about to release our first release of Open Daylight, the Hydrogen release. At the time, I joined the project, that's a couple of months ago, and now it was really in no state to be usable. It was a bunch of great minds and a bunch of great ideas and some code, but nothing really usable yet. So, let's get into it. Before we get into the details, just a bit of a background about what it is we intended to do. So, in Open Daylight, there was already a lot of support for OpenFlow. And OpenFlow is actually the protocol that will, yeah, basically replace your control planer and your switches. So, you have the data forwarding plane, which actually takes packets from A, dumps them on port B, and then you have the control plane. And for those of you who have been in networking, that's usually the stuff you configure using Telnet or SSA to go in, you tell the port is part of a certain VLAN, or actually you tell the router, you tell the switch how to make its decisions on where packets should go. And if you're using software to find networking, it's usually the controller that's going to be telling the switch how to do it and where to forward packets. And the way the controller tells the switch how to forward packets and what to do with certain packets coming in on port, that's the OpenFlow protocol. So, the OpenFlow protocol is actually a really simple rule-based protocol. You build a table of rules into your switch, and a rule can be as simple as A packets coming in on port one. Please tag it with VLAN 100 and send it out on port B, or send it to a controller, which is really interesting. So, you can suddenly send A packets coming in on port one. You can send it to a controller, control it, pick it up, look at it, make some intelligent decision about where this packet should go, and send that conclusion back to the switch. The OpenFlow plugin was pretty much already in Open Daylight at the time. So, it was mostly used to control the hardware, as the, you know, say the first step of software to find networking, controlling your switches from a central controller instead of going into the switch and doing SSH stuff. That was already in Open Daylight. But the thing missing there is actually the control layer. As we now have a lot of hypervisors, and we want to do virtual networking on hypervisors, there's a layer between the hardware we have in the data center and the VM running on a hypervisor. And this layer in most often is Open V-switch nowadays. So, Open V-switch is a real switch in any sense of the world. It, yeah, the packet forwarding supports all kinds of open standards. But there's one tricky problem with Open V-switch is it has no fixed hardware. If you look at a real switch, the one you put in your data center, it has like 24 ports. You can give them a number, port one, port 24. And it's fairly easy to understand if you want to configure something in port one, you configure it in port one. If you have Open V-switch, it's actually far more complex because how many ports do I have? Where are my ports? Where are they, how, what do they look like? Are they interfaces? Are they bridge ports? Are they patch ports through other switches? And that's where the OVSDB interface comes in. It's like the meta-management system of the Open V-switch. You can tell it to create a port because, yeah, if you want to create a booted virtual machine, it needs a virtual interface, and the virtual interface needs to be plugged onto the Open V-switch. And for that, you need a port. If you have multiple switches inside your Open V-switch and you want to connect them, you need to create patches between the two ports. That's all done using software. And the software doing it is the OVSDB daemon. And the OVSDB daemon uses an JSON RPC protocol, which is called, yeah, OVSDB protocol. And it provides you with centralized management of your Open V-switches, so you can really configure all the stuff you need to configure from a standpoint point. At the time when I got into the project, the OVSDB plugin wasn't really well-defined yet. It was a couple of ideas about where we wanted to go, where we wanted to take the plugin, but a lot of, yeah, bright ideas, but no real conclusions yet. So that's actually the point where the integration starts to be really interesting. Up in that point, it was all like Google research and downloading the code, doing a lot of Git clones, trolling through the mailing list, our guys, and seeing what actually happened. This was a scary bit about the integration, because suddenly I had to talk to a human about this. And it was really, it was a very nice experience. I mean, everybody working in open-source communities knows that if you join a new community, it can be either a very friendly community or it can be a hostile community or it can be a community that completely ignores you. In this case, I found two people, or actually I found a lot of people, but two people really stood out. I got in touch with Brandt Settlesbury. I don't know if you guys know him better as the name Network Static, but if you don't, please look up his blog. If you ever want to know something about Open V-switch and software-defined networking, it's on his blog. And I hope I just pronounced his name right. I'm not sure. Those guys really welcomed me with open arms. They sat down, made a lot of time. I mean, I was on IFC for about an hour talking to these guys, and then they said, hey, we're going to open up a Google video call. Why don't you join? And we're going to sit down and really explain what you need to know and how we can help you. And before I know it, I was actually, yeah, part of a community. I mean, and there was like in two or three hours' time, I was part of a community that I've never been part of. And that's really a great welcoming community. And I think that's really part of what Open Source is all about, is being friendly to each other and helping each other out. So I had a couple of new friends, and we started to sit down and say, OK, so what are you guys working on? Well, we're working on a lot of things. For example, one of the discussions we're having is like, OK, we wanted to do integration, and they were working, mainly working on integration with OpenStack, and I was working on integration with CloudStack. And we're having discussions like, where actually do we want to integrate? There's multiple levels available in Open Daylight. Open Daylight is such a flexible platform, you can integrate on the very low level, and with low level, an OVSDB plug-in really meant like Open Daylight being a portal into OVSDB, like a wrapper. It would just be a wrapper between the OVSDB protocol and the REST API provided by Open Daylight, allowing me direct interaction with the OVSDB. On the other hand, there were also various levels of higher layer APIs. So the first question everybody asked, and we asked the same question from the OpenStack Neutron perspective and from Plaza perspective, what is it we actually want to do? Where do we want to integrate? So there was a lot of fun discussions. It was really about what is the purpose of each project? And finally, we sort of sat down and decided, OK, we want the cloud management systems to do just that, cloud management. Leave them to do the orchestration bit, leave them to actually select what needs to be done, and then trust the Open Daylight part to actually do the stuff. I don't need to know how you create a port in OVSDB. I don't need to know that if you create a network interface, you first need to create a port and then attach it to the interface. That's actually not that interesting to me. I just want to make sure that if I have a port, I can tell something that I need a port, all the relevant parts will be done. And the next thing was, OK, so now we've decided that we're going to put a lot of intelligence, or at least a lot of the day-to-day heavy lifting in the Open Daylight OVSDB plugin. Where are we going to put the brains? Who's going to be responsible for knowing what to do? Who's going to be the owner of the current state? Again, that's an interesting discussion. Cloud management systems traditionally have a view like they own the world. Cloud management system is the boss. It knows it, and every other system has to comply to their wishes. It might be a very good idea, because cloud management system is supposed to have a very overall, very broad view about your entire setup. But on the other hand, stuff like Open Daylight, it knows a lot about the network. So where do we actually put the real interesting data, like what are the connected hypervisors? Who's in charge of knowing what kind of switches are available? Who knows which ports are enabled and which ports having a certain administrative state? We spend a lot of time discussing this, and actually we haven't found the real answer yet. At the moment, we say cloud management system owns the state. So the amount of which hypervisors are connected to a particular network, which virtual machines are running on a particular network, is the state that is in the cloud management system. So if there's any kind of disruption in communication between Open Daylight and any cloud management system or stuff, that's where we're actually going to look. So we're going to look towards the cloud management system and say, OK, let's push new data, sync the data into Open Daylight. That's one too fast. And there's actually some timing issues. Open Daylight is a very, very important thing. There's a lot of timing issues. Open Daylight was slated to have a release on December 9. The first hydrogen release, we slipped a bit with the release date, so we're now actually closing in on the release date. So we had a lot of great ideas in Open Daylight where we wanted to go. We wanted to create an OVSDB plugin that would really allow you to manipulate any kind of OVSDB type of system, implementing the JSON RPC protocol to manage OVSDB. And we wanted to have another OVSDB plugin that would actually do all the heavy lifting of working with Open V-switch and actually making it into a system that allows you to plug multiple types of OVSDB using modules in there. We just couldn't get it done with the time available and with the people available. So we ended up with a sort of hybrid solution where we have a almost generic OVSDB integration, which implements the protocol as defined in the request for comments. But it's also mixed with a lot of higher level codes where we make decisions which are particular for Open V-switch. Like we know that Open V-switch, if I create a bridge, I need to create the bridge and I need to add it to the Open V-switch database. That's something that's really specific for Open V-switch. At the moment, it's still in the generic OVSDB code because at the time it was the best solution for the release. Might not be the best or the most ideal solution, but for now it's where we actually may progress and we actually have some working stuff out there in the release. So again, there was a lot of discussions going on in the weekly meetings about what actually is, what do we want to do and what's feasible to actually do in a project. But in the end, we got things done. So I'm just focusing on the cloud stack side here, but actually we got OVSDB. We got the module done. We got it into a release state. We managed to get a really stable API out there. There's a neutron integration for OVSDB and there's a cloud stack plugin. And the cloud stack plugin is now pushed into the ACS master branch, so it's later for the next release. Not going to be in a 4.3 release, but hopefully it's going to make the 4.4 release. It depends a bit on where we go to in the open dialyte project and the cloud stack project, but for now we're hoping that we have a stable controller platform in open dialyte so we can push a stable plugin with cloud stack for the next development iteration. So let's get a bit into detail about what we built. So in the setup, like I explained in the beginning of my talk, the purpose was to have a couple of KTM hypervisors and be able to build an overlay network between them. So my test setup consists of two KTM hypervisors, open pre-switch installed on them, a cloud stack management server, and an open dialyte controller. It is actually a pretty easy setup. You can set up in virtual box on your own machine. There's some pre-setup that you need to do. We couldn't get everything in time into the OVSDB plugins or there's a couple of configuration issues you need to do if anybody wants to repeat the tests. Just shoot me an email or contact me on REC and we'll get you sorted. Everything else actually done by software. So in open in cloud stack, we built a plugin and part of the plugin we created the UI and part of the UI is actually adding and the controller. And here we try to keep stuff as simple as possible. So by adding a controller to a network or adding a controller to a physical network in cloud stack, it means that you have a construct where you can send commands which you can enable for individual networks. So here's just a simple screenshot. And for those of you who want to know, those question marks are about me not really understanding the internationalization in cloud stack. It should be fixed somewhere. But the main point here is that we can now attach an open daylight controller to a cloud stack physical network. And for cloud stack this particularly means that we have the ability to configure it, to use it, and to make it part of any user's network. If we want to make it part of the network for a particular user, we use a model that's called the offering model in cloud stack. So in cloud stack, if I want to give something, make a resource available to a user, I create an offering. And an offering consists of several settings. For example, if you have a compute offering, it can be a number of CPUs, a couple of megahertz or amount of memory. And in this case, we're focusing on the networking offerings and on the networking offerings. I'm actually going to tell the end user, OK, this is where you need the, which services are going to be available on the network, which functions do you want on the network, and which providers do you want to use for those particular applications? So as you can see here, for example, port forwarding uses the virtual router provider, which is the, yeah, basically network function virtualization construct that actually provides a low-balancing firewalling, et cetera. And for the virtual networking, we're using the open daylight plugin. Virtual networking is the name we've used to select which software-defined networking vendor is actually going to be used to provide this particular network service. So with this offering, we can actually allow the user to create a network. So up at this point, it's all admin work. And from here on, it's actually up to the user to actually do stuff. So this is what the user actually does. So the user, the first thing the user usually does is he creates a network. In Cloudsector, say, if you use UI, you create a network. And when you create a network, you actually create an instance into the network. So this is part of the open daylight UI. And the code inside the plugin that we've written works in the following setup. You create a network in Cloudstack. Nothing happens yet. You create your first virtual machine in Cloudstack, and the network switches from state allocated to state implemented. During the implementation phase of this network, it will actually start to create a couple of things. So the first hurdle we had to solve here is how to get the configuration that we know about the hypervisors into the open daylight controller. There were two trains of thought here. First of all, it's like, OK, if we connect the open daylight controller, we can immediately push our entire cluster setup to open daylight and make sure it's all preconfigured. And we went this route at the first iteration of the plugin, but actually decided not to pursue this. The problem here is that if you make changes to your cluster setup later on, you need to have some kind of synchronization between open daylight and Cloudstack to say, OK, I'm adding a host to my cluster, and now I'm suddenly going to have to add it to open daylight as well. We decided for this first version to go for a really easy way of doing it. Just when you boot a virtual machine, it knows where the virtual machine is going to be provisioned, and when the virtual machine is provisioned, it knows that to push that particular configuration to the hypervisor. So when the first virtual machine is actually provisioned, it's called to open daylight saying, OK, I've got a new hypervisor. Can you connect it? And this is a call to the connection manager API in open daylight. The connection manager API will actually create a new node in open daylight of type open vSwitch and will connect the OVSDB plugin. And part of connecting the OVSDB plugin is an auto-discovery process that will discover all the existing switches on the OVSDB and actually create two specific switches. And one of the switches that creates is the BRInt, which is, we call it the integration bridge. This switch is configured to use normal switching capabilities and have VLANs. So any machine you connect to it in a particular VLAN will be available to all the other machines on the same switch in the same VLAN, just like you would in regular sense. And the other one is the BRTUN. And the BRTUN interface is a flow-controlled switch, meaning that without actually pushing any flows, nothing will happen on that switch. And this is the one we're going to use later on to actually drive traffic using the overlay network to the other hyperfisers in the network. When this switch is actually provisioned and the open daylight reports that it now knows about this particular hypervisor, we send it a network. And for us, this was actually interesting because here we're using the Neutron API. So Neutron has a concept about networks and ports. And we reused that particular idea to push our own data into the system. So we push the network. We give it a unique identifier, which is the same as the unique identifier used for the network in CloudStack. And we push a port. And a port here is like a virtual network interface. So at this point, there's only a single machine running on the hypervisor, but we already know about the hypervisor. And we know that there's an open daylight, suddenly knows that there's a network with a certain UUID. And there's at least one machine configured to use this network with a certain UUID. The second step is when you boot the next virtual machine. And now I'm going to assume that you use a system that allows you to make sure that this virtual machine boots on the second hypervisor. Otherwise, it would be a very boring talk. So we're going to actually go through the same motions again. So we start the virtual machine. CloudStack will try to look up the hypervisor. And it sees that it doesn't know about the hypervisor yet by sending a call to the connection manager saying, hey, do you know about this particular IP address? No, I don't know about this particular IP address. So it sends another connect call to the hypervisor. At that point, it will run through the same procedure, set up the BR int, set up the BR done, and basically return back to CloudStack. OK, it's done. Well, we already know about the network. That's something we can actually check. So what's interesting, magic, happens when we actually start a port. By starting the port on the second hypervisor, we're actually sending a signal to OpenDailite like, OK, I've got a machine living on hyperversion number one, and I've now got a machine running on hyperversion number two. OpenDailite recognizes that those two ports belong to the same network. If they belong to the same network, it means that we need some kind of configuration between the two. It checks if there's actually a tunnel interface between the two. So this is really the magic of the open, of overlay networking. When it sees that there needs to be communication between the two hypervisals, it will create a tunnel. In this case, we're using GRE tunnels, but we can just easily switch them to VXLan tunnels or any kind of tunneling system currently supported by OpenVswitch. And then we need to start provisioning flows. And the flows is really telling the system what to do. So on the BR int, we're using the regular switching flows. We're using VLANs to separate the individual networks. So every network in neutral has a building in VLAN in the OpenVswitch that we use to communicate between the BR int and with the patch port that's going to the BR tunnel. And on the BR tunnel, we're going to use flows. The fun part here is since we already have all the information in the port, so we know exactly what MAC address is used, we know which IP address is used, we can make really detailed flows what we want to happen. So we're not using any controller magic yet, but we're really pushing static flows like, okay, I know if I get a packet from this particular MAC address and its destination is this other particular MAC address or it's going to be in this network, I'm going to push it to this particular tunnel. Every tunnel has a separation idea, so we know that a tunnel belongs to a certain network. So by pushing this flow on the tunnels or all the tunnels, the moment you have more hypervisals, we know that the traffic is isolated and only belongs to a certain network. And it's also a built-in security because it's automatically antispoofing. You can't just push any MAC address on a network and expect it to be delivered to the other end of the network. It will actually only work if you have the correct MAC address. But since we are a cloud management system, we know the MAC addresses of all the machines we make. We have a built-in security, some kind of port isolation, and we try to limit the traffic over the various tunnels to not completely saturate the tunnels if the traffic has to go to another space or another hypervisor. An open daylight performs all this completely automatically. There's nothing I need to do from Apache Cloud Stack to actually make this happen. All the flows get pushed. There's going to be a couple of special flows pushed to allow the traffic to go out into the tunnel. And actually, when flows exit the tunnel on the other end, we will see, okay, this is part of tunnel number A. Tunnel number A is part of network VLAN 100. So we're actually going to distribute this particular packet, send it back to the BRN, tankless VLAN 100, and with VLAN 100 it will be sent to the individual virtual machines on each side. And then you have the moment everybody was waiting for. And we have been established a network connection. So is this going to be it? No. Like I said in the beginning of my talk, open daylight is really a project that supports a lot. It supports open dove. We don't do that yet. It supports virtual tunnel network. We don't do it yet. It supports something that I haven't thought of and we don't support it yet. So this is very much a work in progress. I'm happy I was, I'm allowed to show it here to tell people a little bit about the overlay networking, but there's so much more that can be done. So it's really just the first step in the whole process of getting support for open daylight. A lot of people were mentioning already, yay, Apache Classics supports open daylight. What we do, but it's only really a first step. There's so much more to do, and I really hope we can continue working on this. And next to having a technical advantage of being able to leverage two different projects, we've actually seen a lot of community advantages to actually working with two projects. Because we are now talking, there's people from Apache Cloud Stack, talking to people from open daylight, people from open daylight talking to Apache Cloud Stack. And actually in all the discussions we had in the channel and all the other environments where we met up, we're actually talking with a lot of open stack people as well. So we're trying to really coordinate and get a lot of ideas going. If you put more than a couple of geeks in the room, you get a couple of great ideas. So even here in Fosname this year, by talking to people you get more ideas about networking, more ideas about how to share ideas. So this plugin for Apache Cloud Stack, it was co-developed by people working on open stack. They didn't write any code, but they contributed ideas and they gave feedback about how to work. And the same went the other way around. By being there in the channel, having discussions about what this project should do and where it should be going, we helped each other. So for me, this was really a nice example about open collaboration and really the power of working in an open source community. So this actually brings me to the last point. Yeah, if you have any bright ideas about where this should be going, feel free to ask or make any comments. So that's it. A little bit faster than I initially expected. So hopefully a lot of time to answer any of your questions. So any questions? No? Okay. Thanks a lot.
 OK, I just got a thumbs up so we can get this show on the road.  Everybody still awake? Hello?  Wow! This is pretty awesome for FOSDEM that everybody is still awake.  I hope you like it. I chose a black background,  so nobody has to look at really bright colors.  I tried to keep the images a bit low, so everybody who has a hangover like me  should be pretty much OK with the presentation.  This presentation is an adventure story, and so I chose this image to kick it off.  It's an adventure story about how I got involved with Apache Cloudstech.  It comes to get most of that part, but especially...  Five minutes early.  Yeah, he gave the thumbs up, so he said, get started.  You want to wait?  Yeah.  So even though we're five minutes early, we get started anyway.  You know any jokes?  No, actually not.  I'm a dead serious guy. I don't do jokes.  Sorry.  So, who am I?  Well, I'm Hugo.  Working as a mission-critical engineer for Sjubak Filles back in the Netherlands.  I'm also part of the project management committee of Apache Cloudstech.  Contributors open daylight, especially on the OBSDB part,  which I will be telling about today.  And actually, if I have some spare time, I try to spend it behind one of my playstations.  Though, unlucky for me, I don't have that much time for it nowadays,  since I'm working on all those projects.  If you want to reach me for some reason, there's a lot of contact details over there.  Please try not to tweet too much during the presentation,  otherwise my pocket will keep on buzzing.  So, what I want to do today is tell a bit how I got involved with the Open Daylight project.  Open Daylight is a project.  There's a lot of noise going about Open Daylight.  And, yeah, I decided to have a look at what it is, what can be used for,  and especially since I'm working with the Apache Cloudstech project as well,  and my main focus within Apache Cloudstech is software-defined networking.  Open Daylight for me was really interesting to look into.  So, I'm going to tell you a little bit of background about Apache Cloudstech,  a little bit of background about Open Daylight.  I'm going to ask a question that everybody should be asking in this room,  why the hell would you want to integrate those two projects?  And I'm going to tell a bit about my adventure stories.  And the adventure part here is what actually happens if you decide to take a step  and integrate two projects.  So, Apache Cloudstech.  Apache Cloudstech is an IAS.  It's a cloud management system.  It orchestrates your hypervices, it orchestrates your networking,  and it orchestrates your storage.  It's a mainly Java-based project.  It's been around for quite a long time.  Though it gained the most momentum actually when it joined the Apache Software Foundation,  but it has been existing for quite a while before that.  We currently on our, yeah, on the release 4.3,  or close to releasing 4.3,  pretty stable platform, a lot of enterprises actually using it,  we get a lot of positive feedback both from open source communities,  but also from commercial parties who are building businesses around Cloudstech.  So, it's really gaining a lot of momentum.  And one of the things I like about the Apache Cloudstech bit of software is that,  yeah, it supports a multitude of different hypervices, networking platforms, etc.  Here's some of the networking platforms that we support.  We support NTP, we support Midokora, we support Stratosphere, Big Switch.  The unlucky part for a lot of people is that most of these offerings are actually commercial offerings.  So, hence I'm really glad I can actually be here and talk about integrating an open source  software-defined networking platform.  And that's this one.  That's Open Daylight.  Well, actually Open Daylight is a lot more.  Open Daylight is quite a big project.  There's a lot of big vendors and a lot of enthusiastic volunteers working on the project.  And it's really, it's more about facilitating the community.  It's about providing a stable, available controller platform  that can support a variety of software-defined networking tools,  but also network function virtualization.  It literally does a lot.  I listed a few of the things that I found, but, yeah, there was a session earlier yesterday  about application archeology.  I think that's suited this, really dive into it and see what it all supports.  It's almost impossible to keep up.  Everything okay? Seems to be tech, no problem?  Just on the screen.  Okay.  So, the things I've been looking at is mainly at the network virtualization part,  and then you hit stuff like OpenFlow, you hit stuff like OVSDB,  virtual tenant network, OpenDov, PEDTES,  yeah, they're support for the board, support hardware,  it supports software switches, really a lot of things.  So, when I found Open Daylight and started looking into the project,  I said, okay, there's some serious potential here.  It has the possibility of working with an open community,  working with an open source software,  basically get my needs for Apache Cloud Stack and have them with an open project.  So, that was actually the tricky part.  So, what is it exactly that I need?  So, then, yeah, looking at the Apache Cloud Stack networking setup,  it's the basic of what we do with the networking part of Apache Cloud Stack.  We're like, okay, so, what do we have in Apache Cloud Stack?  So, we have basic networking.  Basic networking is, well, basically the old Amazon-style networking,  everything on a big, flat IP network, isolated using security groups  and some foo-doo that deals with filtering MAC addresses, et cetera,  to make sure you have some kind of tenant isolation.  Then there's the advanced networking.  It's actually, well, not even as advanced, but that's how it's called at the moment.  But the advanced network, the difference here is that it is layer two separation.  So, it's really, you get your own private broadcast domain  and actually we're using, yeah, I think nowadays it's called network function virtualization.  We use a router construct that deals with all the stuff,  like routing, firewalling, low balancing, et cetera.  And it sits between your network and the outside world  and allows you to make use of its services  and also give you some privacy on your own network.  We support Virtual Private Cloud,  which is actually a, yeah, it's almost the same as an isolated network,  except it's a multi-tiered network.  And for me, the advanced networking is really the most interesting bit.  I'm the company I work for.  We actually, we're users of CloudStack.  We're not selling any products based on CloudStack.  We're not involved in the community.  We're not selling hardware.  Anything, we're just users of CloudStack.  For us, it's really...  Speed up.  Okay.  So, is this better?  Yeah.  Okay, sorry about that.  Let me repeat.  We really need the basics about networking  because it's actually the most important part  that we will be talking about for the rest of the presentation.  So, there's basic networking, separation based on L3,  and there's advanced networking with separation based on layer two,  individual broadcast domains.  And as I was saying, I'm really a user of CloudStack.  We use it to, inside our company for a lot of different purposes.  And for me, the advanced networking is really the interesting thing.  We have a lot of networks.  We have a lot of time, a lot of minutes,  and VLANs just didn't cut it anymore for us.  So, quite a while back, we actually switched to using  software-defined networking.  And software-defined networking really fits with the advanced  networking model where we can create isolated broadcast domains  on any kind of infrastructure without having to rely on switches  doing a lot of the VLAN work,  going into the switches, configuring them.  So, we're really a fanatic user about software-defined networking.  So, we were already using it,  and I was working with the NISTERA MVP mostly,  and then I found the Open Daylight project.  With my hat on as Apache Project Management member committee,  it was an easy decision.  We need to do something with Open Daylight.  It's a fantastic project.  A lot of nice people over there.  It's supporting just about anything you can find in a networking stack  at the moment that's open and available.  And, well, as Apache CloudStack,  we're a cloud management system where, basically, an orchestrating party.  If there's nothing we can orchestrate with,  we are a pretty useless project.  So, orchestrating with Open Daylight means for us that we can actually  be part of a bigger, we can expand our ecosystem,  we can expand our usability for our users.  So, it's really a good match, and, yeah, it's an open project,  so that was great.  And one of the other big reasons is that there was a lot of talk about  should we be doing something with SDN.  Of course, we had support for software-defined networking vendors already  in CloudStack, but, yeah, you want some open solution,  you want somebody, people can just download, use,  and build software-defined networking with in CloudStack.  So, we already have some support.  We have support for VXLAM, we have support for GRE.  So, basically, we're already acting like a bit of a controller,  but there's people, actually, more knowledgeable about building controllers.  We are really good at orchestrating stuff,  and maybe we should leave the networking controller a bit  to actually all the projects who have the networking people  and know how and the technologies that actually do it.  And Open Daylight is one such project.  They really have the knowledgeable people about software-defined networking,  so we can leverage those, yeah, those great minds  and get our stuff for free.  And, of course, as everybody here knows,  it's actually quite fun to do such a project.  So, this one for me, the fun started.  So, I already found Open Daylight, I was getting involved,  and I was like, okay, now I have a project with about 20 sub-projects.  What the hell am I going to support here?  So, it was really time to sit down and say,  okay, what is actually that I want to do?  I can just about integrate anything from Open Daylight,  but what's actually useful from a user perspective,  what's useful for me to do as a first step in the integration part.  So, I said, okay, my goal is going to be,  I want to have a couple of KVM hyperfixes,  I want to be able to build an overlay network between those hyperfixes.  Really, the bare bones about what it is that virtual networking provides you,  overlay networking provides for you.  So, I decided, okay, that's going to be pretty easy,  so it's on to the API.  That's actually going to be a really tricky bit,  but I'll explain that later.  Because then we found the next problem.  Yeah.  What the...  I mean, okay, I said I want KVM support,  I want to build an overlay network.  There's actually quite a few projects providing overlay networking in Open Daylight.  There's virtual tenant networking, there's Open Dove,  and there's the Open OVSDB plugin that works together with the OpenFlow plugin.  For me, I selected the OVSDB and OpenFlow plugin,  mainly because this stuff I'm familiar with.  I'm already used to working with OVSDB, I'm used to working with OpenFlow.  So, for me, it was something I could understand it, I could work with it.  And, at the time, it seemed pretty easy to get into.  How wrong I was, because it was nowhere near finished.  I mean, we're currently just about to release our first release of Open Daylight,  the Hydrogen release.  At the time, I joined the project, that's a couple of months ago,  and now it was really in no state to be usable.  It was a bunch of great minds and a bunch of great ideas and some code,  but nothing really usable yet.  So, let's get into it.  Before we get into the details, just a bit of a background  about what it is we intended to do.  So, in Open Daylight, there was already a lot of support for OpenFlow.  And OpenFlow is actually the protocol that will, yeah,  basically replace your control planer and your switches.  So, you have the data forwarding plane, which actually takes packets from A,  dumps them on port B, and then you have the control plane.  And for those of you who have been in networking,  that's usually the stuff you configure using Telnet or SSA to go in,  you tell the port is part of a certain VLAN,  or actually you tell the router, you tell the switch how to make its decisions  on where packets should go.  And if you're using software to find networking, it's usually the controller  that's going to be telling the switch how to do it and where to forward packets.  And the way the controller tells the switch how to forward packets  and what to do with certain packets coming in on port,  that's the OpenFlow protocol.  So, the OpenFlow protocol is actually a really simple rule-based protocol.  You build a table of rules into your switch,  and a rule can be as simple as A packets coming in on port one.  Please tag it with VLAN 100 and send it out on port B,  or send it to a controller, which is really interesting.  So, you can suddenly send A packets coming in on port one.  You can send it to a controller, control it, pick it up, look at it,  make some intelligent decision about where this packet should go,  and send that conclusion back to the switch.  The OpenFlow plugin was pretty much already in Open Daylight at the time.  So, it was mostly used to control the hardware,  as the, you know, say the first step of software to find networking,  controlling your switches from a central controller  instead of going into the switch and doing SSH stuff.  That was already in Open Daylight.  But the thing missing there is actually the control layer.  As we now have a lot of hypervisors,  and we want to do virtual networking on hypervisors,  there's a layer between the hardware we have in the data center  and the VM running on a hypervisor.  And this layer in most often is Open V-switch nowadays.  So, Open V-switch is a real switch in any sense of the world.  It, yeah, the packet forwarding supports all kinds of open standards.  But there's one tricky problem with Open V-switch  is it has no fixed hardware.  If you look at a real switch, the one you put in your data center,  it has like 24 ports.  You can give them a number, port one, port 24.  And it's fairly easy to understand  if you want to configure something in port one,  you configure it in port one.  If you have Open V-switch, it's actually far more complex  because how many ports do I have?  Where are my ports?  Where are they, how, what do they look like?  Are they interfaces? Are they bridge ports?  Are they patch ports through other switches?  And that's where the OVSDB interface comes in.  It's like the meta-management system of the Open V-switch.  You can tell it to create a port because, yeah,  if you want to create a booted virtual machine,  it needs a virtual interface, and the virtual interface needs to be plugged  onto the Open V-switch.  And for that, you need a port.  If you have multiple switches inside your Open V-switch  and you want to connect them, you need to create patches  between the two ports.  That's all done using software.  And the software doing it is the OVSDB daemon.  And the OVSDB daemon uses an JSON RPC protocol,  which is called, yeah, OVSDB protocol.  And it provides you with centralized management  of your Open V-switches, so you can really configure all the stuff  you need to configure from a standpoint point.  At the time when I got into the project,  the OVSDB plugin wasn't really well-defined yet.  It was a couple of ideas about where we wanted to go,  where we wanted to take the plugin,  but a lot of, yeah, bright ideas,  but no real conclusions yet.  So that's actually the point where the integration  starts to be really interesting.  Up in that point, it was all like Google research  and downloading the code, doing a lot of Git clones,  trolling through the mailing list, our guys,  and seeing what actually happened.  This was a scary bit about the integration,  because suddenly I had to talk to a human about this.  And it was really, it was a very nice experience.  I mean, everybody working in open-source communities  knows that if you join a new community,  it can be either a very friendly community  or it can be a hostile community  or it can be a community that completely ignores you.  In this case, I found two people,  or actually I found a lot of people,  but two people really stood out.  I got in touch with Brandt Settlesbury.  I don't know if you guys know him better  as the name Network Static, but if you don't,  please look up his blog.  If you ever want to know something about Open V-switch  and software-defined networking, it's on his blog.  And I hope I just pronounced his name right.  I'm not sure.  Those guys really welcomed me with open arms.  They sat down, made a lot of time.  I mean, I was on IFC for about an hour talking to these guys,  and then they said, hey, we're going to open up  a Google video call.  Why don't you join?  And we're going to sit down and really explain  what you need to know and how we can help you.  And before I know it, I was actually, yeah,  part of a community.  I mean, and there was like in two or three hours' time,  I was part of a community that I've never been part of.  And that's really a great welcoming community.  And I think that's really part of what Open Source is all about,  is being friendly to each other and helping each other out.  So I had a couple of new friends, and we started to sit down  and say, OK, so what are you guys working on?  Well, we're working on a lot of things.  For example, one of the discussions we're having is like,  OK, we wanted to do integration, and they were working,  mainly working on integration with OpenStack,  and I was working on integration with CloudStack.  And we're having discussions like, where actually do we want  to integrate? There's multiple levels  available in Open Daylight. Open Daylight is such a flexible  platform, you can integrate on the very low level,  and with low level, an OVSDB plug-in really meant like  Open Daylight being a portal into OVSDB, like a wrapper.  It would just be a wrapper between the OVSDB protocol  and the REST API provided by Open Daylight,  allowing me direct interaction with the OVSDB.  On the other hand, there were also various levels of higher  layer APIs. So the first question everybody  asked, and we asked the same question from the OpenStack  Neutron perspective and from Plaza perspective,  what is it we actually want to do?  Where do we want to integrate?  So there was a lot of fun discussions.  It was really about what is the purpose of each project?  And finally, we sort of sat down and decided, OK,  we want the cloud management systems to do just that,  cloud management. Leave them to do the orchestration  bit, leave them to actually select what needs to be done,  and then trust the Open Daylight part to actually do the stuff.  I don't need to know how you create a port in OVSDB.  I don't need to know that if you create a network interface,  you first need to create a port and then attach it to the  interface. That's actually not that  interesting to me. I just want to make sure that if I  have a port, I can tell something that I need a port,  all the relevant parts will be done.  And the next thing was, OK, so now we've decided that  we're going to put a lot of intelligence,  or at least a lot of the day-to-day heavy lifting in the  Open Daylight OVSDB plugin. Where are we going to put the  brains? Who's going to be responsible  for knowing what to do? Who's going to be the owner of  the current state? Again, that's an interesting  discussion. Cloud management systems traditionally  have a view like they own the world.  Cloud management system is the boss. It knows it,  and every other system has to comply to their wishes.  It might be a very good idea, because cloud management  system is supposed to have a very overall,  very broad view about your entire setup.  But on the other hand, stuff like Open Daylight,  it knows a lot about the network.  So where do we actually put the real interesting data,  like what are the connected hypervisors?  Who's in charge of knowing what kind of switches are  available? Who knows which ports are enabled and which  ports having a certain administrative state?  We spend a lot of time discussing this, and actually  we haven't found the real answer yet.  At the moment, we say cloud management system owns the  state. So the amount of which hypervisors  are connected to a particular network, which virtual  machines are running on a particular network,  is the state that is in the cloud management system.  So if there's any kind of disruption in communication  between Open Daylight and any cloud management system or  stuff, that's where we're actually going to look.  So we're going to look towards the cloud management system  and say, OK, let's push new data, sync the data into  Open Daylight. That's one too fast.  And there's actually some timing issues.  Open Daylight is a very, very important thing.  There's a lot of timing issues.  Open Daylight was slated to have a release on December 9.  The first hydrogen release, we slipped a bit with the release  date, so we're now actually closing in on the release date.  So we had a lot of great ideas in Open Daylight where we  wanted to go. We wanted to create an OVSDB  plugin that would really allow you to manipulate any kind of  OVSDB type of system, implementing the JSON RPC  protocol to manage OVSDB. And we wanted to have another  OVSDB plugin that would actually do all the heavy lifting of  working with Open V-switch and actually making it into a system  that allows you to plug multiple types of OVSDB using modules  in there. We just couldn't get it done with  the time available and with the people available.  So we ended up with a sort of hybrid solution where we have  a almost generic OVSDB integration, which implements the  protocol as defined in the request for comments.  But it's also mixed with a lot of higher level codes where we  make decisions which are particular for Open V-switch.  Like we know that Open V-switch, if I create a bridge,  I need to create the bridge and I need to add it to the Open  V-switch database. That's something that's really  specific for Open V-switch. At the moment, it's still in the  generic OVSDB code because at the time it was the best solution  for the release. Might not be the best or the most ideal  solution, but for now it's where we actually may progress and  we actually have some working stuff out there in the release.  So again, there was a lot of discussions going on in the  weekly meetings about what actually is, what do we want to do  and what's feasible to actually do in a project.  But in the end, we got things done.  So I'm just focusing on the cloud stack side here,  but actually we got OVSDB. We got the module done.  We got it into a release state. We managed to get a really  stable API out there. There's a neutron integration  for OVSDB and there's a cloud stack plugin.  And the cloud stack plugin is now pushed into the ACS master  branch, so it's later for the next release.  Not going to be in a 4.3 release, but hopefully it's going  to make the 4.4 release. It depends a bit on where we go  to in the open dialyte project and the cloud stack project,  but for now we're hoping that we have a stable controller  platform in open dialyte so we can push a stable plugin with  cloud stack for the next development iteration.  So let's get a bit into detail about what we built.  So in the setup, like I explained in the beginning of my  talk, the purpose was to have a couple of KTM hypervisors and be  able to build an overlay network between them.  So my test setup consists of two KTM hypervisors,  open pre-switch installed on them, a cloud stack management  server, and an open dialyte controller.  It is actually a pretty easy setup.  You can set up in virtual box on your own machine.  There's some pre-setup that you need to do.  We couldn't get everything in time into the OVSDB plugins  or there's a couple of configuration issues you need  to do if anybody wants to repeat the tests.  Just shoot me an email or contact me on REC and we'll  get you sorted.  Everything else actually done by software.  So in open in cloud stack, we built a plugin and part of the  plugin we created the UI and part of the UI is actually adding  and the controller.  And here we try to keep stuff as simple as possible.  So by adding a controller to a network or adding a controller  to a physical network in cloud stack, it means that you have  a construct where you can send commands which you can enable  for individual networks.  So here's just a simple screenshot.  And for those of you who want to know, those question marks are  about me not really understanding the internationalization  in cloud stack.  It should be fixed somewhere.  But the main point here is that we can now attach an open  daylight controller to a cloud stack physical network.  And for cloud stack this particularly means that we have  the ability to configure it, to use it, and to make it part of  any user's network.  If we want to make it part of the network for a particular  user, we use a model that's called the offering model in  cloud stack.  So in cloud stack, if I want to give something, make a  resource available to a user, I create an offering.  And an offering consists of several settings.  For example, if you have a compute offering, it can be a  number of CPUs, a couple of megahertz or amount of memory.  And in this case, we're focusing on the networking  offerings and on the networking offerings.  I'm actually going to tell the end user, OK, this is where you  need the, which services are going to be available on the  network, which functions do you want on the network,  and which providers do you want to use for those particular  applications?  So as you can see here, for example, port forwarding uses  the virtual router provider, which is the, yeah, basically  network function virtualization construct that  actually provides a low-balancing firewalling,  et cetera.  And for the virtual networking, we're using the open  daylight plugin.  Virtual networking is the name we've used to select which  software-defined networking vendor is actually going to be  used to provide this particular network service.  So with this offering, we can actually allow the user to  create a network.  So up at this point, it's all admin work.  And from here on, it's actually up to the user to  actually do stuff.  So this is what the user actually does.  So the user, the first thing the user usually does is he  creates a network.  In Cloudsector, say, if you use UI, you create a network.  And when you create a network, you actually create an instance  into the network.  So this is part of the open daylight UI.  And the code inside the plugin that we've written works in  the following setup.  You create a network in Cloudstack.  Nothing happens yet.  You create your first virtual machine in Cloudstack, and the  network switches from state allocated to state implemented.  During the implementation phase of this network, it will  actually start to create a couple of things.  So the first hurdle we had to solve here is how to get the  configuration that we know about the hypervisors into the  open daylight controller.  There were two trains of thought here.  First of all, it's like, OK, if we connect the open  daylight controller, we can immediately push our entire  cluster setup to open daylight and make sure it's all  preconfigured.  And we went this route at the first iteration of the plugin,  but actually decided not to pursue this.  The problem here is that if you make changes to your cluster  setup later on, you need to have some kind of synchronization  between open daylight and Cloudstack to say, OK, I'm adding  a host to my cluster, and now I'm suddenly going to have to  add it to open daylight as well.  We decided for this first version to go for a really easy way  of doing it.  Just when you boot a virtual machine, it knows where the  virtual machine is going to be provisioned, and when the  virtual machine is provisioned, it knows that to push that  particular configuration to the hypervisor.  So when the first virtual machine is actually provisioned,  it's called to open daylight saying, OK, I've got a new  hypervisor.  Can you connect it?  And this is a call to the connection manager API in open  daylight.  The connection manager API will actually create a new node in  open daylight of type open vSwitch and will connect the  OVSDB plugin.  And part of connecting the OVSDB plugin is an auto-discovery  process that will discover all the existing switches on the  OVSDB and actually create two specific switches.  And one of the switches that creates is the BRInt, which is,  we call it the integration bridge.  This switch is configured to use normal switching capabilities  and have VLANs.  So any machine you connect to it in a particular VLAN will be  available to all the other machines on the same switch in the  same VLAN, just like you would in regular sense.  And the other one is the BRTUN.  And the BRTUN interface is a flow-controlled switch,  meaning that without actually pushing any flows, nothing will  happen on that switch.  And this is the one we're going to use later on to actually  drive traffic using the overlay network to the other  hyperfisers in the network.  When this switch is actually provisioned and the open daylight  reports that it now knows about this particular hypervisor,  we send it a network.  And for us, this was actually interesting because here we're  using the Neutron API.  So Neutron has a concept about networks and ports.  And we reused that particular idea to push our own data into  the system.  So we push the network.  We give it a unique identifier, which is the same as the  unique identifier used for the network in CloudStack.  And we push a port.  And a port here is like a virtual network interface.  So at this point, there's only a single machine running on  the hypervisor, but we already know about the hypervisor.  And we know that there's an open daylight,  suddenly knows that there's a network with a certain UUID.  And there's at least one machine configured to use this  network with a certain UUID.  The second step is when you boot the next virtual machine.  And now I'm going to assume that you use a system that allows  you to make sure that this virtual machine boots on the  second hypervisor.  Otherwise, it would be a very boring talk.  So we're going to actually go through the same motions again.  So we start the virtual machine.  CloudStack will try to look up the hypervisor.  And it sees that it doesn't know about the hypervisor yet by  sending a call to the connection manager saying,  hey, do you know about this particular IP address?  No, I don't know about this particular IP address.  So it sends another connect call to the hypervisor.  At that point, it will run through the same procedure,  set up the BR int, set up the BR done,  and basically return back to CloudStack.  OK, it's done.  Well, we already know about the network.  That's something we can actually check.  So what's interesting, magic, happens when we actually start  a port.  By starting the port on the second hypervisor,  we're actually sending a signal to OpenDailite like,  OK, I've got a machine living on hyperversion number one,  and I've now got a machine running on hyperversion number two.  OpenDailite recognizes that those two ports belong to the same  network.  If they belong to the same network,  it means that we need some kind of configuration between the two.  It checks if there's actually a tunnel interface between the two.  So this is really the magic of the open,  of overlay networking.  When it sees that there needs to be communication between the two  hypervisals, it will create a tunnel.  In this case, we're using GRE tunnels,  but we can just easily switch them to VXLan tunnels  or any kind of tunneling system currently supported by OpenVswitch.  And then we need to start provisioning flows.  And the flows is really telling the system what to do.  So on the BR int, we're using the regular switching flows.  We're using VLANs to separate the individual networks.  So every network in neutral has a building in VLAN in the OpenVswitch  that we use to communicate between the BR int and with the patch  port that's going to the BR tunnel.  And on the BR tunnel, we're going to use flows.  The fun part here is since we already have all the information  in the port, so we know exactly what MAC address is used,  we know which IP address is used, we can make really detailed flows  what we want to happen. So we're not using any controller  magic yet, but we're really pushing static flows like,  okay, I know if I get a packet from this particular MAC address  and its destination is this other particular MAC address  or it's going to be in this network,  I'm going to push it to this particular tunnel.  Every tunnel has a separation idea,  so we know that a tunnel belongs to a certain network.  So by pushing this flow on the tunnels or all the tunnels,  the moment you have more hypervisals,  we know that the traffic is isolated and only belongs to a certain network.  And it's also a built-in security because it's automatically antispoofing.  You can't just push any MAC address on a network  and expect it to be delivered to the other end of the network.  It will actually only work if you have the correct MAC address.  But since we are a cloud management system,  we know the MAC addresses of all the machines we make.  We have a built-in security, some kind of port isolation,  and we try to limit the traffic over the various tunnels  to not completely saturate the tunnels  if the traffic has to go to another space or another hypervisor.  An open daylight performs all this completely automatically.  There's nothing I need to do from Apache Cloud Stack  to actually make this happen.  All the flows get pushed.  There's going to be a couple of special flows pushed to allow the traffic to go out into the tunnel.  And actually, when flows exit the tunnel on the other end,  we will see, okay, this is part of tunnel number A.  Tunnel number A is part of network VLAN 100.  So we're actually going to distribute this particular packet,  send it back to the BRN, tankless VLAN 100,  and with VLAN 100 it will be sent to the individual virtual machines on each side.  And then you have the moment everybody was waiting for.  And we have been established a network connection.  So is this going to be it?  No.  Like I said in the beginning of my talk,  open daylight is really a project that supports a lot.  It supports open dove.  We don't do that yet.  It supports virtual tunnel network.  We don't do it yet.  It supports something that I haven't thought of  and we don't support it yet.  So this is very much a work in progress.  I'm happy I was, I'm allowed to show it here  to tell people a little bit about the overlay networking,  but there's so much more that can be done.  So it's really just the first step in the whole process of getting support for open daylight.  A lot of people were mentioning already,  yay, Apache Classics supports open daylight.  What we do, but it's only really a first step.  There's so much more to do,  and I really hope we can continue working on this.  And next to having a technical advantage  of being able to leverage two different projects,  we've actually seen a lot of community advantages  to actually working with two projects.  Because we are now talking, there's people from Apache Cloud Stack,  talking to people from open daylight,  people from open daylight talking to Apache Cloud Stack.  And actually in all the discussions we had in the channel  and all the other environments where we met up,  we're actually talking with a lot of open stack people as well.  So we're trying to really coordinate and get a lot of ideas going.  If you put more than a couple of geeks in the room,  you get a couple of great ideas.  So even here in Fosname this year,  by talking to people you get more ideas about networking,  more ideas about how to share ideas.  So this plugin for Apache Cloud Stack,  it was co-developed by people working on open stack.  They didn't write any code, but they contributed ideas  and they gave feedback about how to work.  And the same went the other way around.  By being there in the channel, having discussions about what this project should do  and where it should be going, we helped each other.  So for me, this was really a nice example about open collaboration  and really the power of working in an open source community.  So this actually brings me to the last point.  Yeah, if you have any bright ideas about where this should be going,  feel free to ask or make any comments.  So that's it. A little bit faster than I initially expected.  So hopefully a lot of time to answer any of your questions.  So any questions?  No? Okay. Thanks a lot.
_FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_0_827.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_828_1547.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_1548_2291.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2292_2351.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2352_2447.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2448_2543.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2544_2591.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2592_2663.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2664_2711.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2712_2759.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_2760_3011.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_3012_4403.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_4404_8171.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_8172_9107.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_9108_9167.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_9168_9359.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_9360_9515.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_9516_9767.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_9768_10043.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10044_10187.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10188_10247.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10248_10307.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10308_10355.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10356_10415.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10416_10463.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_10464_12551.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_12552_12635.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_12636_16247.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_16248_23567.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_23568_24587.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_24588_26255.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_26256_32711.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_32712_32843.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_32844_33983.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_33984_35207.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_35208_43535.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_43536_43607.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_43608_43655.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_43656_43751.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_43752_44039.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_44040_44087.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_44088_44135.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_44136_45035.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_45036_45095.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_45096_45587.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_45588_46187.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_46188_51107.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_51108_55343.png _FOSDEM_2014__Adventures_with_CloudStack_and_OpenDaylight_mYfCAAgPi2s_55344_55344.png