Comment 9 for bug 1915967

In effort to gather use cases for changing a data-port on a deployed node, we’ve gathered the following scenarios that have created situations where data-ports for physical networks/provider networks need to be changed post-deployment:

1. Hyperconverged deployments with nova-compute (with neutron-openvswitch-agent or ovn-chassis subordinate) and ceph-osd co-resident (hulk-smashed) onto the same metal needing to re-deploy a different nova-compute/networking flavor to a hypervisor while having capacity or performance related reasons requiring ceph-osd to stay online on the node.

Hypervisor type A has physnet1 on bond0 fabric
Hypervisor type B has physnet1 on bond1 fabric
Bond0 and bond1 are two fabrics hosted on the same spine-leaf switches
Metal machine X has nova-compute-A deployed as well as ceph-osd as principal units
Expected process:
Remove nova-compute-A unit from metal X
Add nova-compute-B unit to metal X without redeployment

2. Live Re-architecture of cloud networking.

Network team wants to move physnet1 vlans from bond0 fabric to bond1 fabric
Network team enables vlan tagging on the bond1 fabric while leaving them enabled on bond0 fabric.
Current setting for n-ovs-agent is data-port=br-data:bond0
Cloud operator runs juju config neutron-openvswitch-agent data-port=br-data:bond1
Expected results is that bond0 is removed from br-data, and bond1 is added, resulting in very small connectivity loss for that physnet on each OVS.