 So welcome, there are a lot of guys here. Can you hear me in the back? Okay, I will speak louder. And so welcome to my topic. Don't go out of the way, thank you, you have a pen time. Okay, thanks. So today I will talk about something about the Youcheng and something about the code in the Youcheng. And my name is Yongsheng Gong and I'm working for United Stack. And if someone wants to, once that's nice here, you can, I have uploaded to my slides too, that's because of site. So I hope that slides will be there with the videos. And if not, you can find my name on the Neutron project site. So send me the email to ask for the PowerPoint, thanks. So this presentation is deep dive into the Youcheng. So I'm talking about coding. So there will be many codes and some email diagrams. And I cannot guarantee the crapness of some content because the Neutron project is making fast progress every time. Okay, in this session I'm very excited because our Neutron community developers are very active to promote the Neutron project. And I have scanned the sessions list and I found some, this is just a part of this list. So I think these sessions are very informational and very helpful if we want to learn more detail about the Neutrons and the components of it. But my today's presentation is just the beginning, I think. Okay, today I will talk about how the Neutron server gets started from the developer's point of view. And then I will talk about how an API request is processed. I will look at the current default plugin, ML2. And then as we know, the Neutron is consists of many agents, so to learn deeply that the Neutron, we should know how the agents communicate just through the message queue. So the message queue is in Neutron. And then the normal compute, how the normal compute interacts with the Neutron server and asked to develop a Neutron, we should know how to debug the Neutron server. Okay, this is today's contents. Okay, if you want to know the Neutron server, there are some very little features. First one is WSGI, WSGI is a variable server data interface, it specifies how a variable server interacts with web allocations. Now currently, if you type in the Neutron server on a console, then it will start it, Neutron server allocations on the embedded web server. But I have also heard that there are some guys are running Neutron server on the Apache server. Okay, the next skills is the past deploy. Past deployment is a feature to configure the WSGI applications in the servers. And we will look at the past deployment configuration of the Neutron. And the third one is the Python rules. Python rules is very critical here. We use it to form the Neutron server's API layer. We will look at it also. And then the PICCAN, we have some Obstack projects are using PICCAN, but we also have the Neutron community developers also saying we need to do some change. And we have a design summary session there. If you want to know the decisions, you can, well, we can see the iPad of that session. So, okay, so there are diagrams. At the top, it is a Neutron service diagram, at the top, it is API. The API consists of core REST API and extension REST API. And under it is the common service layer. The common service layer will do authentication and authorization and input validation to form the output. And after this common service layer, it is the plugin interface. And then it is the plugin itself. The plugin itself will communicate to agents. So, we will go deep dive into the code to see how these layers are formed, okay? Okay, we have talked about the PACE deployment. This is the Neutron's PACE deployment conversion file. At the top, you can see the Neutron. Neutron is coded into the code. This is the Neutron service application name. Under it, there is the URL prefax v2.0. It is the Neutron version 2 API prefax. And then you can see that the Neutron API v2.0 consists of four components of the PACE components. This is very important if you are talking about some of them. Okay, look here. If you want to profile the Neutron service code, we must find the main functions. Main functions is the engine point. Okay, if you want to track the code from edge. The main engine point to do two important steps. That one is to pass the configuration files. So, it's noted how the whole assistance is config. And then the PACE deployment function is used to note that there's four components. You can see that we have four components and we also have four factory method here. So, this four method will note this four components is back to you. And after these four components, and all these, we will have a pipeline to deal with the API request. Okay, let's look at how the pipeline is used. First, API is issued from a client. There will be one URL request. URL request will come to the first component, Austin token. Austin token is used to do authentications. So, there are some other projects are using Neutron without the keystone. So, in that case, the Austin token can be removed. And then that's why the keystone context, the keystone context, keystone context just converts the Austin token's information, Austin token will turn the information into the Neutron context. The Neutron context is used by the following two components. When the request is equipped with the Neutron context, it will come to the extension component. The extension component will deal with the extension resources API. If it is not the extension API, it will go to our core service, core rest API. If in the core rest API is not found, if it is not found, it will be returned to the user. This is the request pipeline. We will look at, and in the following time, in the following part, we will talk about how the process is, what the process do. Okay, let's look at how the session gets started. In this slide, we can see two important steps, steps A, to create the core plugins, then step B, to load the service plugins. There are two configuration items in Neutron.com. One is core plugin and the other is service plugins. In one Neutron deployment, there's one and only one core plugin configured, but the service plugins, we can have many, such as a firewall service and the node balance service, and the L3 rotor service. So these are, and here here, the plugins are loaded. And what are plugins and extensions? What are plugins and extensions? These extensions are about resources and the actions on them. So you can see that each extension will define one function, get resources. This function will return the resources and actions on them. And the plugins are used to support the resources. You can see that in each plugin class, we will have a supported extension, aligns, member, attributions, it will define what extensions are supported by this plugin. And there are also some functions defined in the plugin class. These functions are resources action handlers. So this is about plugins and extensions. Neutron server has no these plugins and then the extensions will be loaded. Instations are managed by extension manager. The extension manager will search the extensions on the song path. The path can be defined in a Neutron.com by API extensions path to racial items. And you can see that in step A, it will search on the each path to find some specified class name in each module. And this will be the potential extension. And then in step B, the Neutron server will do two kinds of actions. They will check if a potential extension has implemented some immediate interface functions. And in the second section, it will check if one of the plugins is supported. So this is how the extensions are loaded. Okay, now it is time to install the core resources API. The core resources are defined by rotor.py file. Concentrally, we have three kinds of core resources. It is the network, subnet, and the port. Okay, after this step, the core rest API will be constructed and exposed. And now it is the time to assemble the extension rest API. The extension middleware class is used to expose the extension rest API. When the extension middleware is created, it's in dash H, it will get all extension resources from the extension manager. The extension manager will return all of the previous loaded extension resources to the extension middleware. Then the extension middleware will install the Python root object into the WSGI framework. So until this step, all extension URL will be installed and exposed. So let's move to the normal steps to how the Neutron server process and API resources. We have seen that the core rest API, extension rest API, all these API are exposed and then the plugins are loaded. So we will talk about how the API is processed. So you can see, we have a very important object resource. The resource is, you can picture it just as a hook in the WSGI application framework. So if there is API URL coming to the resources, callable method will be called and the resources will initialize the serializer according to the request content type. For example, if it is the JSON request, it will generate JSON decelerizer. If it is XML, XML decelerizer will be created. And then the decelerizer decelerizer method is called to decelerize the request body. When the request body is got, the resources method will be called a controller. A controller will return a response and the resource will serialize it according to it and the API client will get the response. Let's go into some detail about how the controller to call the plugin. This is the important part about the common service layer. So one API is received by the controller will calculate the plugin's handle function according to an action text. After that, the controller will do some authorization and to validate the input. And then the plugin's handle function will be called. And after that, if it is about core resources API, it will send out the HTTP notification. And after that, on step one, four, five, the response will be created. And after that, the API client will get the response. So let's go to talk about some ML2 plugin. The ML2 plugin is controlling the most popular and the default plugin in the neutral project. It has to duplicate it to the latest plugin API and the OpenV-Switch API and some. So it is very, it should be the future trend. The ML2 plugin just can allow us to use different network technology at the same time. For example, you can have some Linux bridge agents, computer nodes. You can also have some OpenV-Switch agents, computer nodes. You can have some Cisco computer nodes or some other vendor specific technology nodes. And this is in one neutral deployment. So now ML2 plugin consists of two important concept, network types and mechanism drivers. Let's look out the setup.cfg file on the neutral project's top directory. We have defined, you can see here some type drivers and some mechanism drivers. And the tool starts the neutral server with ML2 plugin. You must have some, you must define what type drivers and the mechanism drivers are used. So in the ML2.ini file, the type drivers and the mechanism drivers are very important to be considered flowering. Okay, we continue to, we have talked about when neutral server gets started, it will create a core plugin stance. This is about how the ML2 plugin is created. ML2 plugin, in fact, they are two important things to do. Firstly, to initialize the different type drivers and the mechanism drivers. These type drivers and mechanism drivers are defined in the configuration file. And lastly, it will be set up RPC as the message queues. So, that's 49. That is, let's come to the message queues in neutral. ML2 plugin is the core plugin. The core plugin will consider two very important objects to deal with the RPC messages. At the bottom, it is notifier. A notifier object is used to notify that there are two agents, some messages. And then the callbacks. The callbacks is used to receive the RPC messages from various agents, such as the open-v-switch agents, L2-L2-NIS agents, and include the DHCP agents. Okay, this is the RPC structure on the open-v-switch agent. You can see that at the center is the OBS neutral agent. It is the class that when we start the open-v-switch agent, the open-v-switch agent will create one object of OBS neutral agent. OBS neutral agent has one member attribute parking RPC. The parking RPC is used to send the notification or get information from plugins. And the OBS neutral agent class also defines some callback functions. The functions are used to receive the messages from the plugins. So let's get more details. Here are RPC messages from call plugins, from the plugins to L2 agents. The R-part is ML2 plugin. We have said that ML2 plugins will have the notified. So if there are some events that need to send the notification to the L2 agent, one of the major functions will be called. And at the center, it is changes. You can see that all of them are found out as changes. Also there are queues, and each queue is for each exchange. And we also, at the bottom it is OBS neutral agent. You can see that there are some callback functions. We can see the, we can see, we get some for example. If we, if we, if we delete a network, the call, the plugins network, the plugins will call the notify, notify network delete function, the network delete function will send the messages through here. Okay, my god. I'll go back. Okay. Yeah, talk about it. Network delete, and network delete function will send the network delete messages. On this change, you'll come to here, and then the obvious neutral agent, network delete callback function will be called. And in this function, the agent will do whatever you want to do. So let's go from another direction. Sometimes the, sometimes the agent, the agent needs to, needs to actually to communicate with the plugin. So, and the exchange is used is neutral, topic exchange, and the queue is queue plugin. And, and then the, the, the plugin has the, has related to callbacks functions defined. So, for example, get them pull the, get device, get device detail. So, sometimes the agent needs to know something more about a port. So it will call the, it will call the get device details messages, functions. Now get device detail, function will send a message to the neutral queue, to the neutral topic exchange. And then the ML2 plugin, callback function, get device details will be called. And on the plugin side, get device details will to query the database for this port and then return some network information about the port and then return to get, return to the agent. So we have more objects structures. This is GACP agent. You can see that it has the same pattern, same pattern as the OBS L2 agent. At the bottom it has the plugin RPC object that is used to, to communicate with the plugin server. And the, and it also defines some, some, some callback functions that is used to receive the notification from the plugin. We can, here, here is the messages from the neutral server to get the agent. Every API on core resources, such as network subnet and the ports to create and to update the delete or whatever, will send a message to GACP agents. If these messages are targeted to specific GACP agents, the neutral top, the exchange topic and neutral will be used and to, the message will be delivered to specify the GACP agent. If the GACP messages are not targeted to a specific agent, the found out exchange will be used. Such, and this is the GACP agent to, to call plugin. Sometimes GACP agents also need to know more, know something from, from the plugin. I will not talk too much. I think it is a, we have just 11 minutes left. So let's look at how the neutral server interacts with the normal compute. In normal, in normal configuration files there are some neutral server, neutral server-specific configuration actions defined. At the top it is the network API class. If it is not defined as such, the normal network, traditional normal network will be used. So once we want to use the, use the neutral, neutral network, we have more options to define. The red, the red colored options are used to connect to the neutral server. We have neutral URL, and then some, some password, and then the last thing is the VIF driver. The VIF driver is also very important if you, if we want to implement when the specific, specific, specific neutral drivers, neutral plugins. Okay, this is a message flow when we boot which machines on, on, on Nawa. Somewhere in the, in the core stream and Nawa computers to build instance function will be called. In this function, that's the one, allocate network will be created. This from, the allocate network will, will to, will to call the, will call the neutral servers create a port rest API. Once the neutral server receives the API request, the core plugin will, will create the port resources on the plugin side, and then the port information will be returned to the Nawa computer. And then on step three, the, the, the VIF drivers plug, plug as a function will be called. This function, one of the important, important tasks of this function is to add a port for the virtual machines to the, to the OpenV switch bridge. And our busy agent will detect the port is added and he, and the agent needs more information from the neutral server. So on step seven, get device detail, RPC message will be issued to, to the neutral server from RPC queue. After the get the information about the port on step eight, the agent, the agent will set up the OVS port and, and at this time, the virtual machines network connectivity is assured. Then after the important step is to is for agent to notify the neutral server because the, the port is, is up. So this is the step nine update device, device up message is sent. So here we, here we are using previously talked about RPC message and the REST API is called. Okay. It's time to know how to debug the neutral server. The neutral server code is very big so that know how to debug it is very helpful for our developers. And we, the neutral develop, community developers maintain the Viki page. You can, you can have a look at it to know something about, about it. And, and here I will show two ways to debug the neutral server. First is Eclipse PYDev. Because the PYDev is not compatible with the evanage thread. So we must to change the evanage monkey patch function to use the Python standard thread. And then we create a Python debug run conversion in Eclipse and of that okay. We start the neutral server in debug mode. Okay. This is a very, very exciting page I think when a developer see it. Okay. You can see that we can set playpoint at anywhere and also we can see the variables. The, the variables of when the, when the when the server is paused is hitting the breakpoint. You can even set some conditional breakpoint of that you can step over step into it is a very, very convenient. Another, I recommend another way is to use IPDB. IPDB needs to to use IPDB to add the following line to the neutral server. I think it is okay to to add this line into anywhere anywhere in the in the neutral server is called. And then you can start the neutral server. This is the page. When the neutral when the set trace set trace line is hit it IPDB console will be showed. You can use the, you can use the IPDB command such as go to nest, stop, stop and set up breakpoint print the local variables and global variables. Okay. That is very, very exciting towards to. And the difference between IPDB and the PYDev is the PYDev can all, to use the PYDev you must to you must to use the Python thread. And they are because the situation is when the situation is running we should use even a thread. So there are some strange behavior sometimes according to the thread behavior. And IPDB, but IPDB to use IPDB we are still using the eventually the thread so it is, it is more close to the production environment. But the PYDev has a good, has a good interface. Okay. That's, that's all for today. So do you have any questions? So my text will be I think will be, will be show under the, under the video and it's, I will also say if it, if it is not you can always find me on the new Tron project site. Okay, thanks.