 Hello, everyone, welcome. My name is Fernando. I'm a senior software engineer at Rehat. I work for the Networking Services team, mainly focused on network management. And today, we are going to talk about Linux system rules and network config with NMS State. All right, so let's go to the important part. What will you learn from this talk? So basically, when you walk out of the room, you should have learned what is Linux system rules, what is NMS State, how we can mix them, navigating the API of NMS State and the world role, and then the new features of NMS State. So ideally, this should help you to configure all your networking using Ansible and using the rule. So let's go with the first part. All right, what is Linux system rule? So Linux system rule is a set of rules that aim to configure new Linux components for different subsystems. It is a set of rules, but it is also available as an Ansible collection. So if you want to use Ansible collection, feel free to do it. We must say that it tried always to use native libraries subsystems instead of using CLI commands. So all the time that we tried to do it, we used the libraries directly. And it supports a lot of those subsystems, like Portman, Selenux Storage, Network, SSH, FreeEPA, many of them. But today, we are going to focus on the network rule. So OK, the network rule. So the network rule supports two providers. One is network manager, and the other provider is init scripts. We are going to forget about init scripts. Let's focus on network manager. And it supports a lot of features, for example, of interface types like Ethernet, BLAM bond, bridges, a lot of them. IPv4 and IPv6 address configuration, DNS configuration, routes, routing policy, DNS option configuration, some other utilities like ATH2 or authentication, wireless. Yeah, plenty of them. Let's check first some examples of Linux system role configuration file. The main thing that we are going to focus here is that when using the network manager provider, we are going to focus on connections. So as you know, network manager has their own configuration files, which are called connections. So we define a variable, which is network connections. And in this variable, we define the properties. In the end, what we are doing is translating a key file to a general file. So we have the name of the connection, the state, the type, the interface name, and some other configuration that we would like to use. For example, IP address or bond options like the mode or some other options like Green Moon or whatever. And for example, in this specific example, we are defining a bonding interface and attaching an Ethernet interface to it. So we can see we have the controller property here. We need to define the ATH1 connection. And then we are going to define the bonding connection. I'm showing this because my idea of this is show you then later the difference with the NMS state configuration. In the other side, we have Ethernet with a B-line in top of it. So we have an Ethernet with the name connection plot, and type Ethernet, auto-connect, state up. The interface name here, we are using just a body envelope from the top. We could place whatever we would like with our DHCP configuration, and then we have a B-line configuration with B-line ID 100. It's quite simple because I wanted to use simple examples to see better the difference. So basically, this is the network role when using the NM provider and when using the network connections body up. Now, oops, let's talk a little bit about NMS state. So what is NMS state? NMS state is a library with an accompanying command line tool that manage the host networking configuration, and it do it in a declarative manner. So it is written in Rust, and we provide a native Rust library, but we also have plenty of bindings to C, Goland, Python, and others. One important thing and the difference is that when defining NMS state configuration files, we focus on the device. We are not going to focus on the network manager details. We are not going to focus on how the specific network manager properties are going to be written. We only want to focus on what the user wants to be configured. So the user can define, for example, I'm the user, and I want a bond interface with type bond with state app. We define the different bond properties like the mode, the options, like MIMON, and the port. And this has the same effect than this. So this is the main difference. Here, we are talking about connection name, interface name. Here, that doesn't exist. We only have the interface name. It's what is interesting to us. And also, NMS state here, we try to help the user. So if the user want ATH1 and ATH2 configure, and the interfaces are present on the system, NMS state will automatically create an Ethernet connection for them, and it's going to manage them, and it's going to attach them automatically to the bond. So you don't need to care about how Ethernet is going to be configured. Obviously, if you want to configure some specific thing on the Ethernet interfaces, you will need to define it. But if not, you don't need to care. Here, you need to define it, because you need to define that it's the controller. The controller is a bond. So more difference. For example, if we create a biland, the difference is that we create the biland, ATH1.100, with the type biland, state op, IPv4, enable true, and the others. All right. So what will happen is, for example, this biland already exists and has something configured, or this bond, for example. In NMS state, it will keep the existing properties and we only replace the one that the user specified. So for example, if the user specified, minimum 100, NMS state is going to set minimum 100. But the other properties are going to be considered and they are not going to be replaced. Here, it is different. And in this case, it will replace the other properties, because in the end, it's rewriting the whole configuration. So this is done because how NMS state works is that it fetched first the existing state. So it fetched the existing configuration, translated to a general file, similar to what we use, match them, and apply them. So it allows us to do what we call partial editing. So that's quite great. But currently, NMS state, by itself, it can only be used on your host. And we wanted to have a tool that can use NMS state across multiple hosts at the same time. And then we thought, the network will work. All right, so let's mix them. Oh, we introduced the network state variable. So when using the NMS provider, I mentioned before the network connections variable. And now we are going to have something different, the network state variable. How it's going to work? In the network state, the user will define the complete network state that wants to be applied. And it's going to do it using the NMS state schema. So in the end, if the user is already familiar with the NMS state API, they don't need to learn something new. They can use the same schema and apply it. As I mentioned before, thanks to this, using NMS state, partial editing is possible. And now it won't replace the existing connections on the system. Not mentioned here, but also very important, NMS state has an extra feature. And it does verification, checkpoints, and dropbox. So when you define an state, we call it desired state. First, NMS state is going to check the current state and say, OK, this is what we have configured. Using network manager feature of checkpoints is going to save a checkpoint. Then it's going to try to apply the settings. If something goes wrong, it's going to revert it. But if it went well, according to Karna, but then NMS state fetched again the existing configuration and compare it with the desired one, and it doesn't match, means that something was not configured properly. So it's going to revert back. Obviously, this can be configured to be disabled, but it's a really, really good feature. Because if you misconfigure something and you re-break your connectivity, it's going to revert back to the state before. And therefore, the matching is going to have connectivity again, hopefully. And also, it's important that it simplifies a lot the API for the user, because we are going to be focused on the interface instead of the NMS connection. In the other hand, it is true that if you are willing to configure very specific NMS details, this is not going to be able to be done by using NMS state, because it's not a scope that we want to cover. All right, so let's see some examples of combining them. As you can see, this is basically an ATHT's Ethernet interface configuration. And here, we have defined network state, and we defined the whole state that we want to configure. In this case, it's Ethernet Configure with IPv4 and IPv6. And that's all. So in my opinion, it's quite clear. And just by looking at it, even if you are not familiar with the API, and it's the first time that you look at it, you should be able to recognize what is this doing. Then we can go to a little bit more complex state. And for example, in this case, we are configuring routes and an ATH1 interface. So the same thing here. We don't define the routes in a specific network manager profile. We just say, I want these routes configured. And NMS state will try to find out how to do it. So the user never need to care about how it is being done. Basically, need to care about what is going to be configured. So all right, so this is a sample of a route with definition, metrics, next hop, table ID, et cetera, et cetera. Then we have another example, which is, for example, network state, and we have a DNS resolver. We can configure the search and the server names. So again, this now needs to be configured per profile. It's going to be configured in the whole networking. And this is quite good, because in the past, for example, if you configure using this schema, if you configure DNS in one interface, and for some reason, you need to drop this interface, the DNS is going to be dropped as well. And this way, you don't need to do it. When you drop an interface, as I say, partial editing is one of the main features of NMS state. NMS state will recognize that in the past, the DNS was configured. So if the DNS configuration is stored in one interface, it's going to move it to another one. And it's going to move it to a different place or a global conflict, in case there is no suitable interface. So it is quite great, because you don't need to keep moving the DNS or roots or routing policy configuration from one connection to another. You just need to configure it once and forget about it until you want to drop it. And all right, so how to navigate the API. The NMS API is declarative. And we try to make it as much intuitive as possible. So it is documented at nmsstate.io, and it uses inclusive language. I recommend you to take a look to our web page. We have documented the Jamel API. We also support JSON, and we also support some libraries like Python, REST, et cetera. And it's also documented. So you can check the library's documentation. All right, and one big benefit that we get on the network role when supporting NMS state is that we don't need to implement things twice. Imagine that we have a situation where our manager have a new feature, and NMS state supported it. If you want to use it for a network role, it's immediately supported. If it is supported on NMS state, because it uses directly. So for the developers, it's quite good, because we don't need to implement things again, again, and again, which is quite common when you have a diamond and a set of tools that interact with that diamond. Also, it's beneficial for the user, because when we fix something in NMS state, it's immediately fixed in network role. Just say that I recommend you to try it out. I would like to hear from your opinion. We have mainly list. The project is on GitHub. NMS state and network role. There should be one more. OK, it's all right. So I would like to hear from you some feedback, questions. Any comment at all? What's the connection to Ansible? Yes, you can use Ansible. I mean, you can use this as an Ansible role. So in case you are configuring or managing your infrastructure to using Ansible, this could be part of your tooling and apply this directly with Ansible, and it's going to be applied to all the hosts that you are managing with Ansible. So could you just pick up? If I have a separate community, yes? On your controller? Like NMCLI? Yes, but as far as I know, for example, if you use, yes, NMS state is basically a client of network manager. So all right, OK. I'm going to repeat the question for the stream. The question was if you need to install NMS state as you install NMCLI in your host to make it work. So yes, but as far as I know, the network role is able to install the necessary tools when needed. So when you try to use it, it's going to install NMS state. Obviously, this is not supported on not supported distributions. So I could check the list, but I think that supported distributions are well sent to us Fedora and I think some more, but I'm not completely sure. It's fine? Thank you. OK, thank you. More questions? Something? No? All right. So I hope you enjoy it and thank you very much.