function _create_svc_vm_port in instance_manager.py cannnot update the VN information

[Zhifei Fang]

see file instance_manager.py in the svc_monitor

see those lines from line 476

for vmi in VirtualMachineInterfaceSM.values():
            if vmi.fq_name == port_fq_name:
                vmi_obj.uuid = vmi.uuid
                vmi_obj.fq_name = vmi.fq_name
                if_properties = VirtualMachineInterfacePropertiesType(
                    **vmi.params)
                vmi_network = vmi.virtual_network
                vmi_irt = vmi.interface_route_table
                vmi_sg = vmi.security_group
                vmi_vm = vmi.virtual_machine
                break

we will select a vmi by matching the port name.

if not vmi_network:
            vmi_obj.set_virtual_network(vn_obj)
            vmi_updated = True

we will update the vmi VN information only if it doesn't have any vn information.

therefore,
in this case:

User create a SI with wrong VNs in my test case is user use same VN for the left interface and right interface, the openstack Nova api gives an error to complain about that the same VN choose:

nova error Network f245f012-f182-44fd-ad06-7a2a85f82a18 is duplicated. (HTTP 400) (Request-ID: req-b7a8a5a3-6b5a-4c6c-9538-17f94e77a155)

Therefore, the whole process of creating SI have been blocked, the vmi don't have any VM, and therefore it will not update the service instance information for the VMI.

Our vmi cleaning process in the svc_monitor.py

line 716:
for vmi in VirtualMachineInterfaceSM.values():
        si = ServiceInstanceSM.get(vmi.service_instance)
        if si and not vmi.virtual_machine:
            vmi_delete_list.append(vmi.uuid)

we only process the vmi that have the si information, so the VMI will not be deleted.

So, when the user correct the configuration, and recreate the service instance with same name again, we will be blocked to the old wrong configuration, because we will not update the new VN information.