What is the business rationale for this exception? Is there a specific customer that needs this RFE?

• This feature would mean full support for the nmstate provider for os-net-config in OSP 17.1.4.  There have been a number of customer bugs with os-net-config using the current ifcfg provider that could be solved if we could offer the ability to migrate them to the nmstate provider.  The most recent example of this is https://bugzilla.redhat.com/show_bug.cgi?id=2305088 .  Additionally, by allowing customers to move to nmstate in 17.1.4 that allows us to end support for ifcfg scripts, which has been already deprecated by RHEL and the RHOS org has to maintain.

Are there any security concerns?

• No.  

What other functions, teams, or DFGs are impacted by this feature?

• There should not be any, since this is transparent for anything using os-net-config.

What is the estimated time to have the upstream work complete and approved?

• Patches have all been filed and are in the process of being approved, ETA less than one week.

What is the time and resources required to test this issue? On what date will automated tests be written and ready to run and report results in Polarion?

All the automation for this is on place as we covered it in RHOSO18.

The estimated completion time is around 5 working days, as we will be running our regression tests and analyzing the results.
The coverage we are planning:
*minor update  17.1.3 to 17.1.4 
*Running greenfield deployment with NM mode 
*Running all of our regression 
*checking that the network config store by default in NM  and all connectivity is working properly 
*Checking that new net config will be deploy as key files
*we are covering all our networks & Interface type like DPDK, SRIOV , nic partitioning: 
  -type: interface
  -type: ovs_bridge
  -type: ovs_bond
  -type: vlan
  -type: linux_bridge
  -type: linux_bond
  -type: ovs_user_bridge
  -type: ovs_dpdk_bond
-type: ovs_dpdk_port 

Is there potential doc impact?

• Yes, we will want to have some kind of document - could be a KB article - that describes the process for migrating from the ifcfg provider to the nmstate provider on an established cloud.

Are there new packages needed that are not packaged in OSP or RHEL? Does it require newer versions of existing dependencies (dependency bumps)?

• No

No new packages or dependencies.
What is the support level? Tech Preview or fully supported

• The goal is fully supported; if we must fall back to tech preview that is still better than the current unsupported state

How invasive is the code? From very invasive, a core change to very isolated, no risk to other components?

• Minimal impact; change is constrained to the os-net-config tool and existing code paths are not affected by this change.

What is the impact to deployment/updates/upgrades/FFU; what are the test plans in these areas?

• Migration from ifcfg provider to nmstate provider would be a day 2 operation, similar to OVS to OVN migration.
• By enabling this in 17.1.4 we can assert in a later version of RHOSO 18 that the nmstate migration happens before data plane adoption, meaning we can end support for the ifcfg provider at some point in RHOSO 18's lifecycle.
• Migration to the nmstate provider would not be offered for customers making use of Multi-RHEL.
• Once this is enabled in 17.1.4 we would need to ensure we have automated testing of data plane adoption from an nmstate environment to an nmstate environment in addition to current ifcfg to ifcfg adoption.