Understand the advantages of using the Nmstate provider over the legacy ifcfg provider for network configuration

RHOSO uses os-net-config to configure network properties on your data plane nodes. You can choose between two os-net-config providers: the legacy ifcfg provider and its replacement, the Nmstate provider. Eventually, support of the ifcfg provider will be deprecated and removed.

The following list enumerates the advantages of using Nmstate:

• Declarative and consistent configuration: Nmstate uses a structured YAML-based declarative model, meaning you define the required network state, and Nmstate ensures it is applied correctly. ifcfg files, in contrast, are procedural and require manually setting values for each configuration, increasing the risk of inconsistencies.
• Automation and integration: Nmstate is API-driven and integrates seamlessly with automation tools such as Ansible, OpenStack, and Kubernetes, enabling large-scale network management with minimal manual intervention.
• State validation and rollback support: Nmstate validates configurations before applying them, reducing the risk of misconfigurations. If an issue arises, it can automatically roll back to a previous working state.
• Support for complex networking: Nmstate simplifies configurations for VLANs, bonds, bridges, VXLAN, and SR-IOV, making it ideal for advanced networking setups.
• Future-proof and actively maintained: Nmstate aligns with modern networking trends and is actively maintained.

Start planning your migration to the Nmstate provider by opening a proactive case with Red Hat.

Develop a schedule with your stakeholders. Plan the migration in batches to ensure continuity of operation. Schedule time to test your migration in a test environment before migrating in a production environment.

Open a proactive support case

Migration to the Nmstate provider is a substantial change. You should open a proactive support case to engage planning and operational support.

Test in a test environment before production

Test the migration in an environment that resembles your production environment.

Migration batch scheduling

Schedule your migration to the Nmstate provider with a batch cadence that works best for your operational needs. Your choices include:

• Migrate all data plane nodes in one migration batch.
• Migrate data plane node sets selectively in one or more migration batches.
• Migrate one or more specific nodes in one or more migration batches.

  Identify the data plane nodes that you intend to migrate to Nmstate in each batch. The nodes in a batch should have similar network configurations.

  Before migrating a batch of nodes, plan for the movement of running instances to other nodes that are not part of the migration batch and will continue to operate during the Nmstate migration.

Operational continuity throughout Nmstate migration

With proper planning and testing, you can expect to run your workloads with no interruption during migration from the ifcfg provider to the Nmstate provider.

• A node will experience a brief period of disconnection after the ifcfg configurations are purged and before the Nmstate configuration is fully applied. That is why you migrate the instances to another node before migrating the node to Nmstate.
• You do not need to migrate all of your data plane nodes at the same time. After you migrate the first batch of nodes to Nmstate, you can continue to operate the remaining nodes with the ifcfg provider.
• You do not need to reboot a node as part of the migration to Nmstate, nor as part of a rollback from a failed migration. Important

  If your attempt to migrate a batch of nodes to the Nmstate provider fails, you can roll back the migration attempt.