networkservicemesh / sdk-ovs Goto Github PK

Expected Behavior

As per feedback given here, make all of sdk-ovs and its dependent relevant sdk-sriov and sdk-kernel server chain elements to follow this guideline: add information/make decisions' on the call side of the Request and 'do work' on the return side

Current Behavior

Currently most of the server chain elements follows the below pattern for doing its work: do_its_work -> return_if_work_fails -> next.Request -> cleanup_its_work_done_previously_when_next_request_fails -> return

We can simplify the forwarder server using the Functional Options Pattern, just as it has been implemented in the sdk.

Expected Behavior

After forwarder stopped any interface created and no longer used should be deleted

Current Behavior

The following interfaces remains in the host after forwarder stopped (graceful termination) even after NSM system removal (kubernetes namespace delete): ovs-system and nsm-br - the main bridge interface used by NSM.

Failure Information (for bugs)

The NSM's main bridge should be deleted when forwarder-ovs is stopped, but to delete the ovs-system is risky. In the case of host-ovs this might be used by others. When the OVS is running inside forwarder pod in case of pod termination the ovs is stopped forcefully without the chance to delete the system bridge.

Steps to Reproduce

1. Start the basic NSM system (registry, nsmgr, forwarder-ovs)
2. Delete the namespace
3. Check the host for remainder interfaces (ovs-system, nsm-br)