 John, please take your seats. So we want to start, please take your seats. Our next speaker is Martin, the rest of the Red Hat, who will talk to us about leveraging the standings and improvements on digitalization.com. Welcome to the session about e-event, FDM, and virtualization. My name is Martin Redkin, and I'm working for the over the networking team. In specific, we'll talk about the integration of the over the project with OpenStack OpenDoorful Network. The agenda for today is... First, I will give you a very brief overview of the software behind networking and the overview of them. Second, a very brief overview of their over networking. Then I will talk about the feature called Over External Network Providers. And last, we'll go over to the integration between Over and OpenDoorful Network, the Over Provider of the End Project. Let us start with a brief introduction to software-defined networking. Software-defined networking is a concept where you programmatically configure all the networking devices in your network environment, such as routers or switches, in order to make your networking environment to appear to have desired logical networking capability. In simple words, if you have a physical environment like we have on the left, we configure the switches in such a way that the device is connected to the network, as you can see as it has a topology on the right. Typical software-defined networking solution is built like this. We have an FGN controller, which takes in the logical network topology that we desire. It reads the physical state of the system, and based on those codes, it computes the networking configuration for our network device, and sends the required configuration to the SDM node. One of the implications of software-defined network is OpenVisual OpenVirtual Network. It's called OVEN central. The level is meant to represent it. OVEN provides us with layers 2 and 3 virtual overlays on top of a number of obvious instances that we have in our system. It gives us logical entities, such as logical switches, which are the equivalent of OVEN networks, or OpenVisual network networks, logical switchboards, logical routers, load balancers, accept control lists, and more. The OVEN architecture. Architecturally, OVEN consists of two layers. We have the OVEN central and the distributed OVEN controller. OVEN central consists of two databases. We have the NORAS database, which holds the logical state of the system, this is the state that we desire, and the SOUTH database. The SOUTH database holds the physical state of the system, and it also holds the meetings between the physical devices and the logical entity. We have something called the NORAS demon. This is a demon that looks at the NORAS and SOUTH databases and updates the SOUTH database to mirror the changes to our logical network technology. The other value is a distributed OVEN controller. It's installed on top of an obvious instance on each of our networking tools. It monitors the SOUTH database to update it with the physical state of the system, and to change the meetings of the logical entities to the physical devices that it controls on the OVEN network. Let us look a little bit deeper into how OVEN works. It consists of three items that enable OVEN. One is a number of obvious instances in our system. The second is the open-to-protocol, which allows us to control the behavior of our obvious instances. And the seventh item is tunnels between our obvious instances. When we look at a basic obvious bridge, it just connects all the ports connected to it to all the other ports on the bridge. Now, let's introduce the open-to-protocol onto it. Now we are able to control the traffic going between our different ports. For example, with some of the simple rules below, we are able to specify that any traffic originating at a port with a source MAC of 1 going to source MAC 3 will be outputted to port 3, but any traffic going from MAC 1 to a destination MAC of 2 and 4 will be dropped. So we are able to divide our obvious switch into multiple logical switches, which will separate the networks into the logical networks. Another item, the tunnels between our obvious instances. If we add another port to each of our obvious instances and connect the port with a tunnel, all the traffic from one switch will be moved to the port, will be moved to all our other switches and in turn all the ports on the other switches will be able to see all traffic originating on the other switches. So in result, what we get is not just multiple switches independently fitted, but one big aggregated switch. When we combine all this, we will have our big aggregated switch consisting of all our switches in the environment, which will be sent divided by using the open-to-protocol and tools controlling the traffic into smaller logical switches. Let me now go over to give you a brief introduction to our other networking. I will skip the introduction to other. If you are interested, please come to our other course in building today. This is how we talk about our native other networking. It's pretty nice, it has nice features like bonding, brilliant support, network filters, but it has some problems too. One, it is based on the Linux bridge, so this is very little networking. If you want to create a network and add some virtual machines to connect some virtual machines to this network, we connect a Linux bridge and we attach our port to that Linux bridge. If we want our network to span over multiple hosts, we have to make sure that the appropriate host we connect the Linux bridge to a nick on the host and we must connect the nick between the hosts. This is a value two connection, so network separation is our problem. Another way that we ensure network separation. Another problem is that since we can only connect one bridge to a network interface, only one network per nick on a host. We can go around this using villains. If we have villains, we can have multiple networks on one nick, but then we must also make sure that our infrastructure is connected to the host support of this. Another probably bigger problem is that our network networking can only control the networks within others and our internal networks can only be controlled by others. So no external control for our network. Now, the problem I mentioned three slides ago about not being able to control our networks from the host side. In the data center, it becomes a problem. The data center is usually not only ordered, we would like it to be sold, but somehow people also want to use other systems. So usually we have multiple systems running in the data center. Systems that need to connect to each other. It would only have a network management confined to our different subsystems and it becomes a problem. What we would like to do is to have one centralized network management system that would allow us to manage the networking over all our subsystems in the data center. So we can create one network for instance that all our subsystems would be able to connect to. The metaphor is probably not a good one. Somebody wanted it out for me today because in the book nobody likes centralized management and they did it away with but in the data center it's actually a good solution. So what we came up with is a feature called external network providers. It allows to externalize their network implementation in order to external network providers. It could be any network management systems out in the market it could be for example OpenStateU from or as you will see later OpenVisage OpenVirtual Network. One problem that we had we had to come up with an API that would allow us to control the external network providers. It was pretty tempting to come up with our own implementation our own API reinventing the rule is always pretty exciting. But instead we have chosen to implement an already existing implementation something that is widely used open and like. So we chose the OpenState network in API. If you want to connect an external network management system all you need to do is make sure it implements the OpenState networking API and you can connect it out of the box. So because of this decision the first implementation that we had was OpenState Neutron. OpenState Neutron uses the OpenState networking API so it was almost just enough to connect it it was working out of the box. The OpenState Neutron external provider is available you can use it it's still in the experimental stage we never finished it in such a way that we declared it ready to be supported. This is because it was not really live the problem was that Neutron itself was pretty complicated just to install the external network provider OpenState Neutron and it had more resources than for already itself. So not many people do. Let me just go over how an external network provider would work in connection with over. We have a scenario where we want to create an external network and then create a port to connect to an external network that we can just create. As the first operation we will go to the other UI and we will click to create a new network. On the other network panel we will just have to click one checkbox make it an external network and choose the external provider that we want to create it on. That request will be sent over using the OpenState Network API to the external network provider. The external network provider would create the network as the second operation it would talk to the external network to the network controllers and create the network in our network meeting process. The second operation we would be creating the port, the veneque on our VM. We want this veneque to be connected to this specific network. What our engine would then do first it would create a port to the external network provider. The external network provider usually it would just create a meeting between the logical port and not yet existing veneque in the system. So probably no interaction with the network infrastructure yet. After creating the port on the external network provider Ovid would send a request to VDSM. VDSM is the Ovid agent on top of our virtualization host telling it to create a veneque on the VM and plug it into the external network. We have a feature in VDSM called hook scripts. Hook scripts are user defined scripts which allow the user to plug in into every single significant life cycle event of a virtual machine. So you can do it either before a life cycle event or after. You can do it before we start the VM after we stop it, before we stop it. The ones that we would be interested in are the hooks relating to networks. For example, in our case this would be before veneque plug and after veneque plug. In one of those tools we would have to tell the network controller on the VM host that a port with such a logical port ID would be plugged into this specific physical port. The network controller usually tells the external provider that this has just happened. We have a new method logical to physical and the external network provider would send a wire of this port to our to our external provider network. Let's recap what we know so far. One fact is that other network management is limited. The second one is software defined networking is not that easy. OpenStack Newton is heavy and complicated. The problem with Oven is that we speak OpenStack networking API. Oven only speaks command line or it speaks obviously protocol. So you have to talk to OBSDB directly. They don't have bigger expressions like network port, you have to do it all manually. So how do we resolve it? If you can guess right I can offer you a free speaker that's the only thing I can offer you. Any tools? Yes. So after the session this time the editor speaker what we decided to do is create a project called Oven Provider Oven. What it does is just an adapter from Oven to Oven so it's an Oven adapter for the OpenStack network in the API. I will go back to the diagram showing Oven architecture adding two items. So on top we have our cloud management system below that we have our Oven cloud management system and below that we have Oven as we saw before. Our cloud management system that is Oven it could be Neutron Neutron is providing support for Oven but as I said previously we don't really need all the complication connected with Neutron we don't need to have a few additional VMs just for hosting OpenStack we don't need all the complicated configurations. What we need is just a really simple adapter that would allow us to use Oven using the OpenStack networking API. So what we have is a really small process the code base is less than 100K and it's really in Python it's just as simple it's just a simple adapter. The job initially was pretty easy the basic entities in OpenStack networking and in Oven are pretty similar the OpenStack network is almost an equivalent of Oven logical switches the ports can be mapped to logical switchboards there are a few small differences like the current relationship in OpenStack the child keeps a reference to its current in Oven is the other way around so initially it was pretty easy what would come in as an OpenStack networking API for here we create a new network to end up with an Oven configuration at least on the right hand side now if you notice the IDs of the different entities are the same so if you don't want to limit your control of Oven just to Oven you are pretty used the Oven tools like the Oven command line using the same IDs you are not only limited to Oven if you want other applications in your data center to also use Oven and to control it you are pretty useful by the way any changes down to Oven externally outside of Oven will be taken care of and Oven will be able to handle this too sometimes the job is not as easy in the case of load balancers we can see on the right hand side that in Oven a load balancer is actually one liner in a logical switch we only have the big property tells us the source IP and the endpoints for which should be used for balancing this one IP in Oven stack the load balancers are much more complicated we have quite a nice hierarchy of different entities that contribute to creating the load balancer the problem is that we not only have to create an Oven load balancer based on the information that we get from Oven stack API that would be pretty easy but we have to also do it other way around so if somebody issues get request he wants to get the information of the load balancer we have to reconstruct the whole Oven structure based on the little information that we have in Oven when we worked on the project we wanted to create an abstraction mail for the Oven database not to deal with the role of the SVP calls every time but to create calls for network calls and so on while working on it we saw that we are not the only ones trying to solve the problem another thing that have exactly the same issue and tried to use also Python project was Oven stack Newton they were the code wasn't complicated but the result was almost the same so we talked to them and we decided to pull the common code out Oven stack Newton was much further advanced than we were so the decision was to take the Oven code out of Oven stack Newton and create a new Oven stack project so this way Oven stack OBSDB project was created if you need higher abstraction API for the Oven database you are free to use Oven stack OBSDB now let us look at what we have achieved the benefits of using the Oven in Oven one is centralized management this is actually a benefit not only for Oven but for all external network providers you can use centralized network management you can manage your networks from outside of Oven you could also use Oven to manage your other networks second benefit is much easier configuration as I said previously native Oven networking it was layer 2 networking now with Oven outside of the host it is layer 3 networking so instead of taking care of the network separation yourself what you need is just layer 3 connectivity between the hosts to create the channel and that's it don't worry about anything else if you are configuring your network the only thing you need to take care of is the network connectivity network configuration is much easier very similar it's resistant to infrastructure changes if you have your hosts connected you need to change anything in the networking infrastructure sure go on just make sure my packets can be routed to the other hosts when working on the provider initially it was supposed to be one of the many network providers in our system we already had the new phone provider there is one external party that is working on their own network provider for Oven legacy solution so it was supposed to be one of many but while creating it we decided that we like it so much that we wanted to be to create a solution next to our networking so now Oven provider is available out of the box it's supported when you install Oven engine and you configure it you can specify the Oven provider Oven to be installed alone with Oven engine it will be automatically configured it will set up all your keys all your connections it works out of the box the second item is the Oven host from the engine from the engine UI you can also request the Oven provider Oven along with Oven and OpenVis which should be installed on your host and to be automatically configured to be used with the engine another benefit it now has an OpenStack network compliant proxy to Oven if you want to use Oven not the other way by using the command line or going into OBSDDR directly you can use it via the OpenStack networking API we tried to advertise this with some other projects and there was some interest in some and we actually managed to convince ManageICU that is a good idea and ManageICU decided to support networking using our networking provider so if you now go into ManageICU you can add networking provider based on Oven our at the beginning for Oven we just needed networks, ports and some that was it we don't need to control anything else in Oven but when ManageICU started using the provider it turned out that they need much more than just the basic entities they need routers, load balancers and access control with probably there will be more so far that's all we want so network ports and subnets we already have that we are almost done implementing routing it's already partly available in our release 4.2 for the next releases we have plans to implement load balancers access control lists there could be other things later on like quality of service et cetera so we are ready in close to the end I was actually told every time I reversed I was much over time so I tried to do I saw out if it's like Oven production I tried to be as fast as possible and it looks like we are much ahead of time the summary I would like you to remember from this session one now on Oven it's not only the Oven it's networking we have the Oven based networking available too using the Oven provider the other item if you are looking for a nice sdx solution a small one you can use Oven using our provider using the Oven stack networking API and deal with high level Oven stack networking extra so thank you do you have any questions excuse me the question is is it for production yes in Oven 4.2 we support networks, ports and subnets this is already supported routers are still anything they are being tested they should be provided they should be supported I don't want to state that really but critical one other feature which is it's probably not not related to the Oven stack network in API our Oven external Oven networks can be connected to to the legacy to the network so you could have a bridge between you can specify a bridge between Oven network and our network any other questions the question is is it possible to use Oven SDV app as a standalone application I don't know by Oven SDV app you mean the Oven stack Oven SDV app right Oven SDV app it's actually it's not a product it's a library that allows people access Oven SDV you have to actually what you have to give it to Oven SDV app is the host of the Oven SDV the talk and passing the type of connection it's an accessibility another key that you need for the SSL connection with this configuration you can use Oven SDV app and you are ready to go with Oven SDV app if you have any further questions I'll be available here for the next half an hour or so and later on I will be at the Oven boost and do it okay Oven thank you