Application contact email(s)
mko@redhat.com
Trademark and accounts
Contributing or sponsoring entity contact email(s)
mko@redhat.com, fge@redhat.com, ellorent@redhat.com
Project summary
NMstate is a project that manages host networking in a declarative manner
Project description
Nmstate is a library with an accompanying command line tool that manages host networking settings in a declarative manner. The networking state is described by a pre-defined schema. Reporting of current state and changes to it both conform to the schema.
When used in the Kubernetes environment it allows for declarative node network configuration through the Kubernetes API.
Nmstate is aimed to satisfy enterprise needs to manage host networking through a northbound declarative API and multi provider support on the southbound.
With hybrid clouds, node-networking setup is becoming even more challenging. Different payloads have different networking requirements, and not everything can be satisfied as overlays. The Container Network Interface (CNI) standard enables different solutions for connecting networks, however, the node must have the networks setup before the pods are scheduled.
Setting up the networks in a dynamic and heterogenous cluster, with dynamic networking requirements, is a challenge by itself - and this is what this project is addressing.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/nmstate
Project repo URL in scope of application
https://github.com/nmstate/nmstate
Additional repos in scope of the application
https://github.com/nmstate/kubernetes-nmstate
https://github.com/nmstate/nmstate.github.io
https://github.com/nmstate/test-env
Website URL
https://nmstate.io
Roadmap
https://github.com/nmstate/nmstate/issues
https://github.com/nmstate/kubernetes-nmstate/issues
Roadmap context
We use GitHub Issues to track planned work. The list is joint for features and bugfixes. Using Github Issues removes administrative burden we would have by maintaining a separate tool.
Contributing guide
https://github.com/nmstate/nmstate/blob/base/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/nmstate/nmstate/blob/base/CODE_OF_CONDUCT.md
Adopters
https://github.com/nmstate/nmstate/blob/base/ADOPTERS.md
Maintainers file
https://github.com/nmstate/nmstate/blob/base/MAINTAINERS.md
Security policy file
https://github.com/nmstate/nmstate/blob/base/SECURITY.md
IP policy
Will the project require a license exception?
No
Standard or specification?
N/A
Why CNCF?
The reason for joining CNCF is to increase participation and diversity of the community of users and developers of nmstate. Based on the feedback received after presenting in external conferences, the lack of vendor-neutral governance is what holds people from joining as more active contributors. We hope belonging to the CNCF will remove this barrier.
Apart from CNCF, initially we have also considered SIG-Network as a governance body. That one however would only fit the kubernetes-nmstate-operator part of the project and not the whole of NMstate (which is independent from kubernetes). Having the operator as part of sig-network would be a good choice, however it would leave us in a position where NMstate itself needs another body. We feel having CNCF for the complete project is better.
Benefit to the landscape
While the ecosystem of overlay networking solutions is very dense, there space of solutions that manage underlay (i.e. host networking) is very sparse. NMstate is a good fit because it started directly on top of NetworkManager which is a very well adopted in the space of operating systems. While their work is not yet upstreamed, we got signals from people running their own forks with support for netplan – those two vastly cover the majority of population.
Managing underlay networking is something that becomes a more and more critical need for users as networking becomes more complicated over the years. We observe that out-of-the-box does not satisfy the needs any more. People are looking for solutions for easy management of host networking and we believe that nmstate is a perfect fit.
While interviewing some of the current and potential future users we have discovered that often they are using a set of in-house written scripts that manage their underlay network. The common observed pattern is that they would like to use an elegant solution, but they are missing an independent project. No matter how mature, a project owned by a single company is not "independent" enough in their lingo.
Cloud native 'fit'
Nmstate has been created with “declarativeness” at its core just like Kubernetes API. Together with the kubernetes-nmstate subproject it provides a set of Custom Resource Definitions (CRDs) to expose this API. Cloud platforms with their evolving networking capabilities are perfect target users for nmstate, whether consumed via Kubernetes or standalone.
We want to highlight that we are not opinionated towards any platform nor orchestrator. Nmstate is a good fit no matter the cloud provider, no matter the orchestrator (or lack). It works in any environment and at its core it does not rely on any provider-specific feature.
Cloud native 'integration'
In the context of Kubernetes, our project complements any solution that provides the overlay networking - OVN-Kubernetes, Cilium, Project Calico, Antrea, KubeOVN and any other. As such, it creates a complete solution for over- and underlay management.
Cloud native overlap
Currently we do not see any projects in the CNCF ecosystem that would overlap with what nmstate provides. While there were discussions about Kubernetes itself to manage host networking, this never resulted in a real implementation. Therefore, we see nmstate as the only CNCF project that manages host networking.
Similar projects
Canonical Netplan
Landscape
No
Business Product or Service to Project separation
Yes, Red Hat OpenShift Networking is a productized version of nmstate. As Red Hat is “upstream first” company, we do not foresee nmstate to be an exception. Development happens upstream and only afterwards the downstream fork results in a product.
Apart from RHEL, nmstate is also productized in SUSE Linux but the same rules as above apply there.
Project "Domain Technical Review"
No response
CNCF contacts
No response
Additional information
Current maintainers are split between nmstate (https://github.com/nmstate/nmstate/blob/base/MAINTAINERS.md) and kubernetes-nmstate (https://github.com/nmstate/kubernetes-nmstate/blob/main/MAINTAINERS.md). As the latter effectively is a sub-project, we would consider merging the maintainers lists if needed.
Please note there are also archived projects marked as "Public archive" in this org too. We are happy to evacuate them outside if it comes to donation.
We are travelling with the project regularly for a few years now and our main target is FOSDEM (e.g. 2023, 2024, 2025) but also smaller events like DevConf and local meet-ups.
Application contact email(s)
mko@redhat.com
Trademark and accounts
Contributing or sponsoring entity contact email(s)
mko@redhat.com, fge@redhat.com, ellorent@redhat.com
Project summary
NMstate is a project that manages host networking in a declarative manner
Project description
Nmstate is a library with an accompanying command line tool that manages host networking settings in a declarative manner. The networking state is described by a pre-defined schema. Reporting of current state and changes to it both conform to the schema.
When used in the Kubernetes environment it allows for declarative node network configuration through the Kubernetes API.
Nmstate is aimed to satisfy enterprise needs to manage host networking through a northbound declarative API and multi provider support on the southbound.
With hybrid clouds, node-networking setup is becoming even more challenging. Different payloads have different networking requirements, and not everything can be satisfied as overlays. The Container Network Interface (CNI) standard enables different solutions for connecting networks, however, the node must have the networks setup before the pods are scheduled.
Setting up the networks in a dynamic and heterogenous cluster, with dynamic networking requirements, is a challenge by itself - and this is what this project is addressing.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/nmstate
Project repo URL in scope of application
https://github.com/nmstate/nmstate
Additional repos in scope of the application
https://github.com/nmstate/kubernetes-nmstate
https://github.com/nmstate/nmstate.github.io
https://github.com/nmstate/test-env
Website URL
https://nmstate.io
Roadmap
https://github.com/nmstate/nmstate/issues
https://github.com/nmstate/kubernetes-nmstate/issues
Roadmap context
We use GitHub Issues to track planned work. The list is joint for features and bugfixes. Using Github Issues removes administrative burden we would have by maintaining a separate tool.
Contributing guide
https://github.com/nmstate/nmstate/blob/base/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/nmstate/nmstate/blob/base/CODE_OF_CONDUCT.md
Adopters
https://github.com/nmstate/nmstate/blob/base/ADOPTERS.md
Maintainers file
https://github.com/nmstate/nmstate/blob/base/MAINTAINERS.md
Security policy file
https://github.com/nmstate/nmstate/blob/base/SECURITY.md
IP policy
Will the project require a license exception?
No
Standard or specification?
N/A
Why CNCF?
The reason for joining CNCF is to increase participation and diversity of the community of users and developers of nmstate. Based on the feedback received after presenting in external conferences, the lack of vendor-neutral governance is what holds people from joining as more active contributors. We hope belonging to the CNCF will remove this barrier.
Apart from CNCF, initially we have also considered SIG-Network as a governance body. That one however would only fit the kubernetes-nmstate-operator part of the project and not the whole of NMstate (which is independent from kubernetes). Having the operator as part of sig-network would be a good choice, however it would leave us in a position where NMstate itself needs another body. We feel having CNCF for the complete project is better.
Benefit to the landscape
While the ecosystem of overlay networking solutions is very dense, there space of solutions that manage underlay (i.e. host networking) is very sparse. NMstate is a good fit because it started directly on top of NetworkManager which is a very well adopted in the space of operating systems. While their work is not yet upstreamed, we got signals from people running their own forks with support for netplan – those two vastly cover the majority of population.
Managing underlay networking is something that becomes a more and more critical need for users as networking becomes more complicated over the years. We observe that out-of-the-box does not satisfy the needs any more. People are looking for solutions for easy management of host networking and we believe that nmstate is a perfect fit.
While interviewing some of the current and potential future users we have discovered that often they are using a set of in-house written scripts that manage their underlay network. The common observed pattern is that they would like to use an elegant solution, but they are missing an independent project. No matter how mature, a project owned by a single company is not "independent" enough in their lingo.
Cloud native 'fit'
Nmstate has been created with “declarativeness” at its core just like Kubernetes API. Together with the kubernetes-nmstate subproject it provides a set of Custom Resource Definitions (CRDs) to expose this API. Cloud platforms with their evolving networking capabilities are perfect target users for nmstate, whether consumed via Kubernetes or standalone.
We want to highlight that we are not opinionated towards any platform nor orchestrator. Nmstate is a good fit no matter the cloud provider, no matter the orchestrator (or lack). It works in any environment and at its core it does not rely on any provider-specific feature.
Cloud native 'integration'
In the context of Kubernetes, our project complements any solution that provides the overlay networking - OVN-Kubernetes, Cilium, Project Calico, Antrea, KubeOVN and any other. As such, it creates a complete solution for over- and underlay management.
Cloud native overlap
Currently we do not see any projects in the CNCF ecosystem that would overlap with what nmstate provides. While there were discussions about Kubernetes itself to manage host networking, this never resulted in a real implementation. Therefore, we see nmstate as the only CNCF project that manages host networking.
Similar projects
Canonical Netplan
Landscape
No
Business Product or Service to Project separation
Yes, Red Hat OpenShift Networking is a productized version of nmstate. As Red Hat is “upstream first” company, we do not foresee nmstate to be an exception. Development happens upstream and only afterwards the downstream fork results in a product.
Apart from RHEL, nmstate is also productized in SUSE Linux but the same rules as above apply there.
Project "Domain Technical Review"
No response
CNCF contacts
No response
Additional information
Current maintainers are split between nmstate (https://github.com/nmstate/nmstate/blob/base/MAINTAINERS.md) and kubernetes-nmstate (https://github.com/nmstate/kubernetes-nmstate/blob/main/MAINTAINERS.md). As the latter effectively is a sub-project, we would consider merging the maintainers lists if needed.
Please note there are also archived projects marked as "Public archive" in this org too. We are happy to evacuate them outside if it comes to donation.
We are travelling with the project regularly for a few years now and our main target is FOSDEM (e.g. 2023, 2024, 2025) but also smaller events like DevConf and local meet-ups.