 Okay, if we are all done, well, let's continue with the next session that is the configurational L2 services over Neutron. What we are going to do here is something similar to what we have done in the previous session that is first deploy Neutron over the Server B. For those of you not attending the previous session, what we have in the laptop environment is two virtual machines, Server XA and Server XB. Just log in, replace the X for the number you see on your machine. You can log into your machine with Staten and Staten, not too tricky. What we are going to do is to deploy a network node over the Server B. So how we are going to do that with PaX stack. For those of you in the previous session, it's the same first step we were doing before. Let's go to Server A. In the root, you will see that there is an answer.txt, so just edit that with whatever your preferred text editor. We have just to change the host, the IPs we are going to use for deploying Neutron. That are going to be the IPs of the Server B on the management network. That for us, if you see that we have X plus 100, just add to your host number 100. So if you have host 1, it's 101. So let's look for config Neutron Server Host and just replace it for the one of Server B and the same for metadata host. So just replace that. For those of you not familiar with PaX stack, what we are doing is just to play with an answer file. You can generate it, surely you know, but with this, with PaX stack and the path. What we are going since this is located here, or should be, what we are going to do is to launch PaX stack like this, like this, from your Server A. So just launch this. This is going to take just some minutes. If you were on the previous session and have any questions on the environment or whatever, just let me know. Yeah, you can use PaX stack as a deployer. So you have the deployer node on Server A and you can execute it. You can define the environment on the answer file so you can have as many notes as you want defined there. So you can deploy network node in one machine, the controller node in another, one service in another machine because you can do whatever you want. You can launch it from your workstation. You don't need to launch it from the server that is going to be the controller. Yeah. Yeah. Repeat again. Yeah, this is, these are just an environment. We have two machines, but you can deploy it to whatever, I don't know if that's your question. Yeah, but yeah, I see what you mean. What we are doing is deploying OpenStack over a virtual environment. But usually you will not have these virtual machines. What you will have is two physical machines that, yeah, yeah, KBM allows you to do that. So you can run virtual machines over a KBM, over a virtual machine running KBM. That is, so you can, you have, yeah, that is, that is, although usually for the controller node, usually most of the people deploy sit on a virtual machine running on a virtualization solution. You don't need a physical machine there. Yeah, because it's like two geeks or, yeah, yeah, usually what people is doing is if you have a database environment that is the one you have in your infrastructure, just create the DBs there, the one for every OpenStack service, and just keep Kiston, Orison, Dami staff on the, well, no, Dami staff. The services, the core services on the controller, but with two geeks or four geeks, so, yeah, the other. All step neutron, yeah, yeah, yeah, yeah, neutron, neutron always should, should run on a physical machine. Yeah, always. Yeah. And it's recommendable to have eight to 16 geeks and a good, an SSD geeks, local, yeah, computer, you have to put there as much resources and as good as you can, yeah, yeah, usually when you, when you talk about computer nodes, you have different generation of computer nodes. So right now in, I don't know if in Havana or Grisly, you can set up like host groups, so you can provide to your user different qualities depending on the, on the group of computer nodes that they are using. So you can have, for example, all ones with eight geeks and SATA-Ds, 10K, and they have new ones with 48 cores and SSD. So it's like, like that, yeah, you need, you need at least, at least two CPUs, two cores and I suppose four geeks or so. It depends, if, if, yeah, in the memory, the amount you provide is the amount you are going to be able to use in the open stack. So if, well, if you have just dummy, dummy machines like the, like the Amazon free dyer, so you can maybe get something, but it's not. This is running in OSP, Rehat OpenStack 4.0, that is Havana, the Havana, and over Rehat Enterprise Linux 6.5. But as Rob said, we are, I think we are going to release soon, sooner or later the Ithouse work. So, okay, so we are done with the, we are done. We have set up the network, the network node using pack stack. So well, it is, it's quite similar to the previous, so we, if we go here, here you can see all the, all the services that have been set up on the, yeah, on the server B, yeah, let me see what they have done, yeah, on the B, sorry. Okay, so you see that Neutron server is there running. Later we will enable both the DHCP agent and the L3 agent, okay, in the B, in the B. We are, we are launching pack stack from server A, but we are installing, it's the same configuration we are, we were doing in the, in the previous session. It's just a controller node and compute node on, on server A and Neutron, on server B. That, that's it. Yeah, it's that, it's that way, yeah. Sorry, repeat again. Yeah, yeah, yeah, I will, I will check with you later, okay? So I will run and I will check. Okay, so what we see here, one, one of the, one of the agents we are going to have in the, in the network node is the OpenB-Switch agent. What we are, we are working here with is with the OpenB-Switch SDN. That is the, is the SDN that we are going to use below Neutron, okay? So yeah, it's a SDN, yeah, yeah, yeah. They call it SDN for, because they, they separate between SDN solution and hardware, direct hardware solution, the one provided by C-Score, by Arista Networks and so, yeah, it's not real, real SDN there, okay? So if you see, this is, this is the, you see that the service, the AM4 OpenB-Switch is running, the one for Neutron, okay? We see here also that this, this AN is using, the Neutron server is using QPID. You can see the configuration of the, okay, as you see in the, if you are not familiar with OpenStack, you will see that this is OpenStack, is all the OpenStack services are quite clean in configuration and in logging. You will have everything for a service and the, slash ETC, slash the name of the service and everything for the logging of the service and the, slash bar, slash lock, slash the name of the service. So it's, it's similar to Neutron, okay? If you go to Neutron, ETC Neutron, you will see that we have everything here. What we are doing here is the, is the usual deployment you can find out there in the manuals, how to send, in the OpenStack docs also, okay? So it's Neutron with OpenB-Switch. How do you specify that with the core plugin parameter, okay? Here we are, we are setting an OBS. Of course, there are others, Linus Bright, Preach, Cisco, Alistar Network, there are, there are many out there, okay? So many more to come, Melanox also provides plugins. So if you have a expensive hardware, try to contact with your, with your hardware provider, your networking hardware provider and surely they will be able to provide you some, some, to point you to the, to the proper plugin for, for Neutron, okay? Because most of the, of the networking providers right now are developing. Same for storage providers, okay? So if you have NetApp, EMC, SolidFire, whatever, you will, you will be able to get those two. Okay. Okay, so as you see here, we have the, well, I showed you the configuration files there. Getting into all the configuration you can do here is, is, will, will take us a week or two. So, well, with, with the, the one pack stack implement when it's deploying, that's worth fine. Okay? You should, you should be able to have, if you are using VLANs, a production environment. So this is, if you want to do fine tuning, just contact Rehat, contact us and we will be able to, to help you with that. Okay? I will, I would like also to show you the, the configuration for the great VLAN thing. Okay? So if we go to OBS, okay, here what we have in the, in the slides, we have the configuration that you should have in plug-in.ini for a VLAN backend. Okay? If you are using VLAN in, in Neutron, you should have something like this. What, what do you see here is the network type you are specifying VLAN in gray would be gray. I will show you later the, the gray version of this, but you will see that it's quite similar. Also we specify here the range of VLANs that we are going to use. Okay? So we are specifying from 1000 to 2000. So if you have a, a, on the service network, the NIC plaque in your network node and your compute node to the service network will be plaque to a switch and in this switch we will use this range of VLANs in order to create the virtual networks in Neutron. Okay? This is where the virtual became the, the physical, okay? So as I said before in the previous session, if you are able to get a, a dedicated switch for deploying this, don't try to do this on, on shared environment, on shared switches and that's, that's mainly in the, if you go to the server zero, to the server B, your server B, you will see the, the configuration for gray. The important thing here apart from the, from the internal bridges that are, are being used for gray is you see that the network time here is gray and what we define here instead of defining the VLAN range, we define the, the range of the, of the gray tunnels. So you see one to one thousand and the IP we are using for creating the gray. So when we create the gray, what we do is to, usually is to have a dedicated network on both the compute nodes, a dedicated NIC on both the compute nodes and the network node and we create a network there that is called the service network similar to the VLAN. And what we do here instead of, we, we associate a IP to that NIC. So you just get all the gray tunnels over that IP and those will be, all the, I mean, get all the networks in the, in, in gray over the NIC, the physical NIC and those will, will be tunneled to the network node. Okay. Well, the important thing you got, you have to get out of here is that it's quite similar to set up a gray tunnel or set up a, a VLAN base neutral. It's just changing some parameters. The only, the only thing you have to care about is just use a dedicated switch. The first time you, you deploy this on, on a real environment and it's possible for, as I said, we have the management network, the service network and we have the pooling network. In the service network, if you are going to have a, a quite a lot of traffic between the VMs or with your storage, it's important that you get a 10G there. Okay. Because if you start to, if you start to get more and more VMs on your environment, for example, 100 or so, you will see decrease on, on performance. So that's our, those are the main ideas, the main ideas there. Okay. And, and this is the second practice we are going to do. This is about to show you that it is quite flexible in neutron to play with agents. So as we saw before, we, we have a OpenB switch agent, okay? So what, what we are going to show you here is that you are able to stop, start, play, play with them and move to other, to other nodes. So first, in order to play with whatever, whatever neutron service you need credentials. What we are going to get here are the credentials from the, for admin on Keystone, okay? These are generated with pack stack. When you run pack stack, you will see that in slash root, slash Keystone RC underscore admin. You will have the, the credential for admin for that Keystone instance, okay? So if you don't believe me, you can just go in yourself, okay? If we go here in root, okay? You see here, and if we cut this one. This is a, you see here that this is just a way to lock yourself into, into Keystone. You look as the admin on the admin tenant with the rehab that is the possible we have set up in pack stack and against the Keystone service, okay? That is, it's been running, it's been run on, this is the server A, okay? Our controller node. So if we source it, we have superpowers, okay? So we can do whatever, whatever we want. We are the root of open stack. So what we are going to do here is to play with a neutron, okay? So if we run a neutron AL list, oh, sorry. I will, I will copy it from server A, that is the idea of the, this is just to show you that you can get the credential for, for whatever, whatever machine and run, and run commands against the APIs of the different open stack services, okay? You don't, you don't need to be on the controller node. You, you can just download this credential to your workstation and, and run against a remote open stack environment. Any command you want, any admin command you want, okay? So if we copy this, or better, yeah, really, really you copy from the machine where, from where you run a pack stack. Because it's there where it is generated. If you run, for example, you use the laptop in order to run it on remote servers, you will have the, the keystone RC admin in the, in your laptop. So it's generated by pack stack on the slash root of your, of the machine that you are using in order to, to, to run the, the pack stack command. You can, you can, you don't need to be on the controller node in order to run pack stack. You can run it remotely just specifying the, yeah, yeah, yeah, that is. So, is, for you, it will be red hat, okay? For me, it's another one, okay? So if we search here, we have, we now have superpowers. So if we run Neutron, you see that we have two agents, two Neutron agents running there. When you run the new, the Neutron command, this is, this is just a client against the server. So if you look for it, it's something like, like this, Python Neutron client, okay? You will have something similar for each service. So you will have Python minus Nova client, minus Glance client. So these are all these commands. If you want to, for example, play from your laptop instead of going to the server, you can just install these commands, these packages, available in all distributions, but better in red hat. And you can just run the commands from your, from your laptop, okay? Not really. So as you see, we have two agents there, two OpenB switch agents, one on server B and one on server A. The idea there is that in the, in the network node, our server B, we are going to have OpenB switch agent running and another one on server A because we have there the compute node, okay? What we are going to do right now, just to show you how flexible this is, we are going to disable and remove the agent from the compute node that we are able, we should be able to, okay? And later we will recreate that. This is good, for example, if you want to, if you want to move the networks. You have several compute nodes and, and you want to isolate one compute node. You can just stop the agent there. And the networks will be managed by the rest of the OpenB switch agents running on the, on the compute nodes, on the other compute nodes, okay? So, first, as you see, we have an ID for each agent. So, the one we are going to, we are going to work with is the one belonging to the server A, the one associated to the compute node, okay? So, we are going to use this ID. You will see that everything on OpenStack has an ID. Virtual machines, ports, networks, and nets. Yeah, that is, that is. So, if you run this command, so agent, you will see that there are many, many options available in Neutron. You can see the information, more detailed information about that agent. So, you can see here whatever information where the, where the agent is, what is the host, ID, and other, other additional information there, okay? What we are going to do is to destroy this, this agent. First, we are going to disable the agent. In order to do this, we, we run this Neutron agent update and set up the state to false to the ID of that, of that OpenB switch agent that is running on the compute node, okay? So, so, so we, we run the command with false to the, to the ID we were using before, okay? And if you, yeah. The issue there is that you will be all the virtual, imagine, this is a virtual, this is a virtual distribute switch, OpenB switch. So, you have instance of OpenB switch, on OpenB switch Neutron, on all the compute nodes and the network. So, if you just disable here and one of the compute nodes, this agent, you, the other compute nodes will not get affected. So, if you imagine you want to, I don't know, do maintenance. Although there are other ways of doing that. But if you, if you want to do maintenance of a compute node, you can just move the VMs, disable OpenB switch there, and then stop the, the machine itself, change whatever, and get it up, and enable again the, the agent. That is, it's a way to, to play with the, with the, with the OpenB switch. It's true that you can do with nobody, you can do like migration and that take care of this. But if you want to fine tune there, you can do like this. It will create the port, it will create the port on a compute node. It will create the port on, yeah, on the, yeah, all the compute nodes, all the agents, all the OpenB switch agents on the compute nodes will be aware of that port. But the one in, in, in the, in the compute nodes we are getting down will not be, will not be aware of that. That's the, yeah, you will have that problem if you have the VM running on the, on the compute node where you are getting down the, the agent. That's the, that's the issue. Okay, so if we run an agent so, agent so you see that right now our, the admin state of the, of the agent is false. Okay, and we can go farther there and go to server A. That is the one we have disabled. If we run, for example, agent list, you will see that we have the two agents. So we can go farther, not just disabling it as you see with false. We can just go to the, to the compute node that we, we have. And getting, getting it down. Okay, so what we do is service neutral OpenB switch. Agent, stop. Yeah, it's a typo. Sorry. The issue, the issue is that the, if you do that on the network node, it will crash. Yeah, yeah. Yeah, if what we are doing, what we are doing is to disabling one of the OpenB switch agents. So if we disable, we disable the one in the network node, everything will, yeah, yeah, yeah. All, all of them. The, the issue is that the, the ones you have in the agents you have in, it's like a client server. You have, it's distributed, but it's a client server. You have the, the core, the server to say, to say so in the network node. Okay. And then you have clients on all the compute nodes. So they are querying all the time to the, to the OBS instant running on the network node in order to know what the configuration needs. Yeah. Yeah, yeah. It's like having the OpenB switch software running there. So you need, you need that. The issue is at the end you have the, the, the configuration of the whole environment is on the network node. So there, there is a database there. So you, you need to, and this is very important. You, you need to care quite a lot about that database because this is, this is your life in, in a, in a production environment. Okay. So we have a stop here. The OpenB switch in our compute node. So if, if we go and list, that's not good. Okay. It's, it, it appears. It's just here as a node happy. Okay. This is because it's on a non, non healthier status. So next thing we can do is to delete that agent from neutral. So in order to do that, we delete it with neutral agent delete. Okay. With the ID of the, of the OpenB, OpenB switch agent. So it's just agent delete. This one. Okay. So if we run our agent list now, you will see that the only one we have is the one for our network node. Okay. But this is not permanent change. So if you want to just get back that, that, that agent, you can just restart, start again the OpenB switch agent on your compute. Okay. And it will be shown there. Okay. This is a way to, although you will see if you, if you start deploying OpenStack environments that you can play with line migration in order to do to run down times on compute nodes when you have a hardware failure. This is a way to, instead of going just with the novel line migration to be able to play with the networking, if you need at any time to disable networking on a given compute host, compute host. Yeah. Yeah, it's on a, you have all the configuration is on a database on the network node. That is the backend indeed. Well, it's a, I don't remember the coffee fight right now, but it's something like ETS, plugins, yeah, I think this one is. So here, somewhere you have, yeah, you see the OBSDB, that is the database where all the information about OpenB switch, all the networking you have configured on your environment is located. So if you restart OpenB switch on the network node, it will, then the setup you have, it will be recreated, although it's not recommended to do that. Yeah, yeah. Usually with networking hardware providers, plugins, they manage everything on the switch. So they just make API calls to the switch. That's the way they work. Okay, so I think that's all for me. So if you have any questions running the workshops, the labs, or any other general question, just let me or any of my colleagues know and we will provide. Yeah. No, no, no, this is OpenStack. Yeah, this is OpenStack. Yeah, yeah, yeah. Let's say, yeah. Yeah, what you have probably now are many, many deployment tools that deploy the OpenStack services. You can deploy, yeah, yeah. You can deploy this, you have the Red Hat, well, several repos where the services are packaged, but all the services are about a client and a server. So you just, as I said, the Python Neutron client, so you just install this and you can query, well, install this, get the keystone credentials, and then you can query the service, the server. I mean, for example, with Neutron, you install Python Neutron client and you can query the Neutron server. That is. And it's independent, you don't need to install all OpenStack in order to play with the client and the server. You can just install Neutron and play with that. Oh, you just see what's there. Yeah, yeah, yeah. That's the good thing about OpenStack. Indeed. Yeah, yeah, yeah, but you can, this is running against a repo. So it's the LDO repo repository. So you can do it by hand. The good thing about this is that, yeah, yeah, yeah, yeah. Yeah, yeah, installing the package is quite, this is the right way to do it if you are starting, but if you are doing it by hand, installing the packages is quite easy. The difficult part is the configuration. Yeah, it's quite a nightmare and usually you have many typos and it's not a funny thing to do. All right, it's time. Okay, so thanks for attending and.