We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Declare your Linux Network state!

00:00

Formal Metadata

Title
Declare your Linux Network state!
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
NMState is a new declarative API that simplifies Linux network management. Various services built on top of Linux need to manage the network configuration. Each service models network entities differently and uses various APIs to change the network state, multiplying the required work. NMState centralizes the challenges by providing a unified declarative representation of the Linux network state and allowing to modify it using the same schema. NMState also provides Ansible network modules to manage Linux systems, conforming to the same uniform schema used to control network appliances. The talk will introduce NMState, its core capabilities, current users and roadmap, including plans for Kubevirt, oVirt, Openshift and Openstack support. Afterwards, the audience will understand the benefits of using NMState to centralize collaboration on Linux network management.
10
58
80
111
137
Thumbnail
15:21
159
Thumbnail
18:51
168
Thumbnail
26:18
213
221
Thumbnail
15:22
234
Thumbnail
49:51
248
Thumbnail
23:06
256
268
283
Thumbnail
28:38
313
Thumbnail
1:00:10
318
Thumbnail
21:35
343
345
Thumbnail
36:13
353
Thumbnail
18:44
369
370
373
Thumbnail
44:37
396
Thumbnail
28:21
413
Thumbnail
16:24
439
455
Thumbnail
25:10
529
Thumbnail
15:36
535
Thumbnail
28:04
552
Computer networkComputer hardwareState of matterSoftwareFlow separationProduct (business)Computer animationXML
Computer networkState of matterKernel (computing)Computer hardwareLink (knot theory)NetzwerkverwaltungPhysical systemKernel (computing)Computer hardwarePoint (geometry)MiniDiscUser interfaceInterface (computing)SoftwareWeightConfiguration spaceLink (knot theory)Product (business)Library (computing)RoutingLatent heatControl flow graphOpen setRight angleWeb 2.0Computer fileComputer animation
Computer configurationScalable Coherent InterfaceLengthComputer hardwarePrice indexKernel (computing)Interior (topology)Slide ruleStack (abstract data type)MathematicsSoftwareLogicComputer animation
Configuration spaceComputer networkKernel (computing)Link (knot theory)Musical ensembleElement (mathematics)Cache (computing)Slide ruleComputer hardwareComputer configurationClassical physicsAsynchronous Transfer ModeAddress spaceBackupComplete metric spaceTraffic reportingGame theoryDeclarative programmingProcess modelingInternet service providerOpen setExtension (kinesiology)State of matterFluid staticsAerodynamicsInterface (computing)InformationNormal (geometry)File formatConfiguration managementDemosceneNetzwerkverwaltungBitState of matterConfiguration spacePartial derivativeBridging (networking)Functional (mathematics)Lattice (order)SoftwareInterface (computing)Physical systemSpacetimeMultiplication signIP addressTemplate (C++)Formal languageMathematicsDeclarative programmingComponent-based software engineeringPoint (geometry)Set (mathematics)Phase transitionProof theoryPurchasingDifferent (Kate Ryan album)Endliche ModelltheorieGroup actionParameter (computer programming)Communications protocolRouter (computing)CASE <Informatik>Similarity (geometry)Data dictionaryType theoryLink (knot theory)WorkloadComputer fileModal logicGastropod shellNetzwerkdatenbanksystemWeightComputer animation
Formal verificationRollback (data management)SharewarePoint cloudAsynchronous Transfer ModeComputer configurationComputer networkInterface (computing)Virtual LANGroup actionSynchronizationRootLoop (music)Process (computing)VotingElectric currentFormal verificationState of matterConfiguration spaceSoftwareLink (knot theory)Physical systemInterface (computing)Scripting languageSharewareRight angleDivision (mathematics)Ocean currentSet (mathematics)Virtual LANPerfect groupSemiconductor memoryComputer animation
State of matterComputer networkModul <Datentyp>Task (computing)Interface (computing)Link (knot theory)Computer configurationAsynchronous Transfer ModeState of matterSoftwareConfiguration spaceModule (mathematics)Declarative programmingLink (knot theory)SharewareIP addressInterface (computing)MathematicsMultiplication signAddress spaceFormal languageComputer animation
Electric currentPoint cloudTask (computing)State of matterInterface (computing)Rule of inferenceAlgorithmic information theoryScripting languageConfiguration spaceConfiguration spaceLink (knot theory)Interface (computing)Table (information)IP addressComputer animation
Task (computing)Interface (computing)Configuration spaceScripting languageComputer networkMusical ensembleLink (knot theory)Asynchronous Transfer ModeComputer configurationPhysicsPrice indexPredictabilityAddress spaceConfiguration spaceIP addressProjective planeScheduling (computing)SoftwareMereologyWeightInterface (computing)State of matterCategory of beingSystem administratorSoftware testingArchaeological field surveyQuicksortFunctional (mathematics)CASE <Informatik>Different (Kate Ryan album)Exception handlingGame controllerComputer hardwareLogicDeclarative programmingLink (knot theory)Computer animation
TouchscreenState of matterRepository (publishing)Software bug
FreewarePlanningRun time (program lifecycle phase)Configuration spaceDifferent (Kate Ryan album)Type theoryInterface (computing)Firewall (computing)DisintegrationRouter (computing)Ocean currentConfiguration spaceInterface (computing)MathematicsSoftwarePhysical systemFirewall (computing)Ring (mathematics)Endliche ModelltheorieWordGroup action2 (number)Formal verificationOpen setCubeVotingDisk read-and-write headState of matterWater vaporComputer animation
Wave packetBitCodePlanningRevision controlFeedbackInterface (computing)Video game consoleRemote procedure callSoftwareMusical ensembleInternet service providerComputer architectureContext awarenessComputer animation
Canonical ensembleComputer animation
Transcript: English(auto-generated)
Hi guys, we came here to talk about a new tool that we are working on. It's called NM State and we wanted to solve a problem of
configuring 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...
Everyone usually needs to handle networking through the Linux kernel and the hardware. When we started seeing what we need,
we started working with IFCFG 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 net links,
net links directly to the kernel 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 needs it.
They need it for IFCFG. They usually use many IFCFG in its case, but sometimes other stuff. Also there are, we have a tool called Cockpit which configures specific... Does anyone know what is Cockpit?
No. So if you want on a CentOS or Fedora system to... Actually it works on others, but if you want to configure disk and networking and other stuff, you have like a web interface that you can configure that. It talks with D-Bus on the Linux and through the network manager.
There is also Ansible. Ansible, does anyone know what is Ansible? Okay. So also Ansible handles networking. It uses many network, NMCLI and the libnm which is like a library that works with D-Bus.
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 iproute2 and you can do this with fcfg files. It's usually three fcfg files, one for bond and another two for the slaves. And you can do that with what we suggest, which is nmstate,
which you declare in YAML or JSON format what you want and then it just does the work for you behind the scenes. So the nmstate is a layer that is above all the others and it tries to use, currently 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 nmstate. One initial goal is to really capture all the network state on Linux, 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 these 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 we're using is also declarative, which is typically also used in other configuration management systems and we don't really care about 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 are inspired by the IETF network modeling working group,
which is using YARN and the NET 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 our setup.
And the other thing is we build 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 M-State in case it cannot go into Network Manager because Network Manager is supposed to be more generic,
but there might be special use cases or workloads that only make sense by M-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 want to move your normal interface
into an aggregated interface, like a link aggregation or a bridge, and something doesn't work in between, you don't want to have a half-configured networking because then maybe you cannot access your system anymore. With M-State, because Network Manager provides this, you can create a checkpoint through the configuration that it takes.
If we just roll back to the previous configuration, we can be sure that either the initial configuration or the other configuration will be available. Initially, we said that we would like to 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 at one point. Therefore, adding support for partial states is also a design goal of M-State.
Currently, we support the basic settings as a proof-of-concept to ensure that you can work with everything. Adanet devices, of course, with basic and dynamic IP configuration, and bonding Linux bridges and initial basic support for OBS bridges. 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 an initial command line interface that's basically just used from our side to test the system easily. It only has three simple commands, shell set and edit.
Here we see the example of M-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. For example, if you now would like to make it static, you only need to change the DHCP parameter to false,
and then apply this configuration, and you would get the same IP address, just a static one, very easily. Since it's written in Python, we also have a very simple similar Python API, where you can just get the state, change something in the configuration.
Since it's declarative, it's just represented by a simple Python dictionary, where the command line will also support YAML 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, the MQ to 9000, then you can apply the 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 ballback works. So on the left-hand side, I have...
Can you see this? Probably not. Can you now see it in the back? Perfect. So at the left-hand side, I have just a command line. On the right-hand side, I'm listing the current network configuration script on the host,
and I have a demo prepared with just a simple state to configure the aggregation and to be done on top of this with two memory devices. And now I can run nmstatectl 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 set absent for both the vlan and the bond interface itself,
and it's gone again. But I also want to show you what it looks like when the ballback kicks in. I will use the mtu example that I set 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 mtu30 is invalid, and we will shortly see at the right-hand side the new configuration, and then the system verifies whether or not the state is valid and then walks back.
So there's now the configuration, and then in the end it notices that the configuration is wrong. So here we see mtu30 is requested or desired, the current mtu is 1500, and therefore it just works back. Now 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? Okay, quite a few people. And are you 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 there 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 design or IP addresses. And with nmstate, 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 nmstate state
because it's just shifting around a few names. I also have a very short demo about this. So I now will just log out and see the link aggregation setup.
I could also set up the IP address, but there's currently a bug, so therefore I will not show this. And then on Ansible playbook, there's this configuration. I forgot the inventory.
And here we see Ansible also managed to set up the bond interface. Here we have that bond configuration.
The next thing that we would also like to enable you is to configure Kubernetes. Thank you, Tim.
Another use case except Ansible, which fits very well to nmstate, at least to the declarative way, is Kubernetes. Does anyone know what is Kubernetes here? Oh, everyone. It's like the new thing. So 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 utilizes the scheduling of Kubernetes to work with VMs.
It's called Kuber, 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, the networking configuration. So we suggested this CRD as an enhancement
to allow declaring what we want to have on the networking of the node. And it is separated into two parts. One is a policy, the node net config policy, which you can set what you want for all of your cluster
with the matching policy, and it will auto-generate for you the desired state 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 eight, I think I set it to eight, eight VFs. Does anyone, I hope everyone knows what the SROV is, right? SROV is like a special NIC that has a function
that it can create virtual interfaces that they are implementing in hardware. So this is like, you could do the same thing with an MTU. You could say, each first interface of ET80 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. It shows you what you wanted and what you got from the node, and if there is a difference, the controller will apply it for you.
We also wanted to share that there are some challenges with this declarative thing, idea. So one of the challenges is that some of the properties that we change, require, not require, they also change others, other properties.
For example, if we set DHCP enabled, we will get an IP address. So this is the desired state, the actual state. So in the actual state, we will see DHCP enabled and an IP address, but this IP address cannot be set now because we have DHCP through.
So there are 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.
Okay, so I guess you're 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 IO. It's available via GitHub, so all the contributions are happening
with full request and issues there. We also have a JIRA bug tracker, or issue tracker where we do screen 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. Ah, that was just that, which has also all the details.
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 we 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. So for example, is it possible to reach a certain system and then fall back or confirm
when the configuration is correctly. And initial idea, why we are already basing our design on the network working group, or metal ring working group, which uses Netcomp and Yang, is to also provide a similar interface directly via nmstate, so all the tools
that provide this can be used. And we are also working on routing and 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
over at OpenStack and Qubr, 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
in this context, there is a talk in the room before I think. So the question was whether or not nmstate
is exposing an external API or anyone in your opinion. So currently the code is only available to run it locally. So the part, for example, you expose it would be to provide a Netcomp interface, which would be something remotely or using Ansible, which uses SSH as a front port 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 a plan for REST or stuff like that.
So it is currently... Do we repeat the question? Oh, sorry.
So he asked if the API is stable enough. Right? It is the amount. So we are trying now to make it stable. We are not expected to change a lot, but it is also we are in version 0.0.5, so 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 version on the API for sure. Do we have a question?
So who will now start using it tomorrow? At least try it? Ah, you will? Great. You can also get some training. Thank you.