 Hi guys. We came here to talk about the new tool that we are working on. It's called NM State. And we wanted to solve a problem of configuring the Linux Networking to several products or several users of it. Some of them are here, but there are many others. So it started, I'm from the Ovid team. And it started with the need to, sorry. Everyone usually needs to hand an air-talking through the Linux scanner and the hardware. When we started seeing what we need, we started working with ICFG files, and then we started working with IP Route 2, which is the IP tooling who knows. And the ATH tool for things like setting the speed of network interfaces. And we even reached a point that we needed the netlinks. Netlink talked directly to the carrier for things like monitoring what is going on. But we noticed very fast that also there are other products, or other solutions that need it as well. So there is also, for example, OpenStack, if anyone knows, which also need it. They need it for ICFG. They usually use many of the ICFG in its case, but sometimes other stuff. Also there are, we have a tool called Cockpit, which configures the specific... Does anyone know what is Cockpit? If you want on a CentOS, on Fedora system, actually it works on other, but if you want to configure disk and networking and other stuff, you have like a web interface that you can configure there. It talks with debuts on the Linux and through the network manager. There is also Ansible. Does anyone know what is Ansible? So also Ansible handles networking. It uses many NMCLI and the LibNM, which is like a library that works with debuts. And there are other stuff that don't know yet that they need to handle networking on the host, like Kubernetes, for example. For now they said they don't mind. They don't care about it, but we think they will care about it soon. And all of this is pretty complicated, causing a lot of duplication of logic and all the tools are replicating their work, and it is not that efficient. So what I wanted to show you now is just a quick introduction to what is NMCLI. So if you want to configure a bond with two slaves, you will need to do this using NMCLI. You can look at it later. You can do this with IP routes too, and you can do this with FCFG files. It's usually three FCFG files, one for bond and another two for the slave. And you can do that with what we suggest, which is NM state, which you declare in a YAML or JSON format what you want, and then it just does the work for you behind the scenes. So the NM state is a layer that is above all the others, and it tries to use, mainly it works with LibNM, which actually triggers Network Manager, but it also is able to do other stuff, like if it's missing from Network Manager, or if there is a third-party vendor, it can do the work for you and obstruct the whole configuration. So let's talk a little bit about the design of NM state. One initial goal is to really capture all the network state on Linux to make sure that everything can be addressed using this API, instead of just having partial functionality and needing different tools to configure the whole network state. And at the same time, we do not only want to allow configuration, but also allow to report the current configuration of the system in the same format, which makes it easy to build on top of this other tools that, for example, do configuration management, because you can easily get a template from one system and apply it to a different one. And the language that you are using is also declarative, which is typically also used in other configuration management system, and we don't really care about, like, which format we use. We only want to make sure that it describes what you want to do, and then if you have some other tool that builds on top of it, you also know what you want to have, and then you can easily map from your custom declaration to our declaration and vice versa. And therefore, we also use, or we are inspired by the IEPF network modeling working group, which is using Young and the protocol to define a common interface to configure network appliances or network devices such as switches, routers and so on. And since we didn't want to invent something new, we also used this as an inspiration for a setup. And the other thing is we built everything on top of network manager, because it's already there and provides a lot of features that you would like to use. And in case there's something missing, as Eddie said, we would just implement it in a state in case it cannot go into network manager, which would be more generic, but there might be special use cases or workloads that only make sense by an in-state. Another advantage that we get with network manager, and that's also known from the configuring network devices is that you can have atomic changes. For example, if you would like to move your interface from normal interface into an aggregated interface like a link aggregation or a bridge, something doesn't work in the team, you don't want to have half-configured networking because then maybe you cannot access your system anymore with an in-state because network manager provides this. You can create a checkpoint through the configuration that it takes. If you just walk back to the previous configuration, you can be sure that either the initial configuration or the other configuration will be available. And initially we said that we would cover the full network state, but at the same time it may be a problem if you don't really care about other changes with something that you want to change in your tool. For example, if you only want to add an IP address, you don't really care about defining all the other components that are involved with this device checkpoint. So therefore adding support for partial states is also a design goal of an in-state. Currently we support the basic settings as a proof of concept to ensure that you can work with everything. Ethernet devices, of course, with basic and dynamic IP configuration and bonding Linux bridges and initial basic support for OBS bridges, but it will be easy to extend this to everything that network manager supports and, of course, we'll also add other devices if necessary. We have initial command line interface that we just used from our side to test the system easily and it already only has three simple commands shell set and edit. Here we see the example of in-state for the ETH0 interface which just uses DHCP support and at the same time you also get the IP address that's currently configured with DHCP in the same format. And if you, for example, now would like to make it static you can change the DHCP parameter to false and then apply this configuration and you would get the same IP address just aesthetic one very easily. Since it's written in Python we also have a very simple similar Python API where you can just get this state change something in the configuration. Since it's declarative it's just represented by a simple Python dictionary where the command line tool also supports Jamel or JSON but you can just use any language that allows to express this so you just change for example here for the first interface DMPU to 9000 then you can apply this state and this is all that's currently required to change the network configuration. Now let's take a look at a short demonstration about how verification with Warbeck works. So on the left-hand side can you see this? Probably not. Can you now see it in the back? Perfect. On the left-hand side I have just a command line on the right-hand side I'm listing the current network configuration scripts on the host and I have a demo prepared with just a simple stage to configure the aggregation and the VLAN with two memory devices and now I can run nmstate CTIS set and apply this state. There you see the configuration appears now I will just edit the current state and all I need is to do set absent for both the VLAN in the bond interface itself then it's gone again and I'm going to show you what it looks like when the Warbeck kicks in and I will use the MTU example that I said before and just set an invalid MTU for example 30 which is way too low and when I now apply this state the system should not be able to finish because MTU 30 is invalid and we will shortly see at the right-hand side the new configuration whether or not the state is valid and then Warbeck so there is now the configuration and in the end it notices that the configuration is wrong so here we see MTU 30 is requested or desired and the current MTU is 1500 and therefore it just Warbeck. Now this I already said that we could use the since it's a declarative language it's very easy to map this to other configuration interfaces and any one of you knows Ansible quite a few people and are using Ansible to configure your network devices so if you also have to configure Linux devices then you might have noticed that you cannot do it in the same way because they are generic modules that are currently available for these network devices this is an example to maybe for example change the network state of the device or configure link aggregation Dlan or IP addresses and with NM state it's very easy to also implement these interfaces or these modules in the same way so for example on the left hand side this would be a very generic configuration to configure link aggregation which would work on any network devices as long as the device name is the same and you have a proper inventory and then it's easy to translate this one into the NM state because it's just shifting around a few names also I have a very short demo about this so I now will just look out and see here I have the link aggregation set up I could also set up the IP address but there's currently a bug so therefore I will show this and then on Ansible Playbook with this configuration I got the inventory and here we see Ansible also managed to set up the bond interface here we have the bond configuration the next thing that we would also like to enable you to configure Kubernetes so thank you Tim another use case except Ansible which fits very well to NM state to the declarative way is Kubernetes which what does anyone know what is Kubernetes here oh everyone it's like the new thing with Kubernetes declarative is the main thing so it fits this scenario and we think at least we have a project, I don't know if anyone knows there is a project to raise VMs using Kubernetes so it is the scheduling of Kubernetes to work with VMs it's called Kube if anyone is interested so we think that because of this need there is also a need to handle the host of the node configuration network and configuration so we suggested this CRD as an enhancement to allow declaring what we want to have as a matching of the node and it is separated to two parts one is a policy the node-net-config policy which you can say what you want for all your cluster with a matching policy and it will auto-generate for you the desired states for each of the nodes we have here one example of that this is an example with SROV so you can say I want for all my cluster for all the nodes in the cluster any interface that has SROV on it I want to configure 8VFs does anyone I hope everyone knows what the SROV is SROV is like a special need that has a function that it can create virtual interfaces but they are implemented in hardware so this is like you could do the same thing with an MTU you could say H first interface of ETH0 of each node please configure MTU 9000 it looks something like that I will not get into the details but you define the policy and it creates for you these states what you wanted and what you got from the node and if there is a difference the controller will apply we also wanted to share that there are some challenges with this declarative idea one of the challenges is that some of the properties that we change not require they also change other properties to the HEP enabled we will get an IP address so this is the desired state the actual state in the actual state we will see the HEP enabled and an IP address but this IP address cannot be set now because we have the HEP through so there are other other like that like the link speed that you wanted one gig and you get maybe 10 gig or things like that so that part needs to be handled currently either by a logic inside an M-state or by the admin that uses it I don't know okay so I guess you are now thinking shut up and take the money so you can get it but you don't have to buy it you can just download it from an M-state at all it's available via github so all the contributions are happening with full request and issues there we also have a JIRA bug tracker an issue tracker where we do spin planning which is also publicly available and it's currently packaged in Fedora and available in a third party copper repository for centers as well that was this plug which has also all the details and the next so the outlook what we are planning to do as well is of course enhance all the interfaces that you might need or we might need and also make sure we already saw the current wallback automatically but you also want to make this possible manually so that you can aggregate your changes yourself and then at the end say commit this then you can add additional verifications for example if it's possible to reach a certain system and then fall back or confirm whether the configuration is correct and initial idea why we are already basing our design on the network working group or modeling working group or let's use netcom and yang to also provide a similar interface directly via an M-state so all the tools that provide this can be used and we are also working on routing firewall configuration which is a little bit tricky because usually on Linux systems in the configuration it's for example tied to the interface but in the modeling it's tied to the router itself and of course integrating it with our open-stack and cube weird we are also currently in discussion with other people about this thank you very much what are your questions if you like you can get a little bit of candy if you need this as an engagement to ask a question by the way if you are interested in Kubernetes with this in this context there is a talk in the virtual so the question was whether or not an M-state is exposing an external API or a new one in locally so currently the code is only available to run it locally so the part for example to expose it would be to provide a netcom interface which would be remotely or using Ansible which uses SSH as a platform as well but currently it's just locally but others could of course build on top of this and provide a remote API as well there was plan for for rest or stuff like that so it is currently sorry so he he asked if the API is stable enough right? so we are trying now to make it stable we are not expecting to change a lot but it is also we are in version 005 so it's we are trying to get some feedback from the community to see how it works and if they have some special if we have some special needs we may change it but we are planning to have versioning on the API for sure so who will now start using it at least try it you will? great you can also get some kind of thank you