fix: Enable remote docker tests

[denis-tingaikin]

No description provided.

[denis-tingaikin]

@NikitaSkrynnik Could you continue this?

[edwarnicke]

@NikitaSkrynnik A few (hopefully) helpful pointers.

Part of what is breaking is that I was sloppy about handling netns in newKernelVerifiableEndpoint and newKernelVerifiableClient.

cmd-forwarder-vpp/internal/tests/suite_kernel_test.go

Lines 78 to 86 in 5007aba

	rootNSHandle, err := netns.Get()
	if err != nil {
	panic(fmt.Sprintf("unable to get root netNs: %+v", err))
	}
	endpointNSName := fmt.Sprintf("nse-%s", randstr.Hex(4))
	endpointNSHandle, err := netns.NewNamed(endpointNSName)
	if err != nil {
	panic(fmt.Sprintf("unable create netNs %s: %+v", endpointNSName, err))
	}

calls netns.NewNamed(...) ... the problem is this switches the netns of the thread on which its called, and we don't switch it back correctly. The result is that some of the threads onto which goroutines may be scheduled are not on the root netns. This is what is causing the EADDRNOTAVAIL error when attempting to listen for a proxy.

The good news is, it can be fixed roughly by:

	rootNSHandle, err := netns.Get()
	if err != nil {
		panic(fmt.Sprintf("unable to get root netNs: %+v", err))
	}
	endpointNSName := fmt.Sprintf("nse-%s", randstr.Hex(4))
        runtime.LockOSThread()
        defer runtime.UnLockOSThread()
	endpointNSHandle, err := netns.NewNamed(endpointNSName)
	if err != nil {
		panic(fmt.Sprintf("unable create netNs %s: %+v", endpointNSName, err))
	}
        if err := netns.Set(rootNSHandle); err != nil { 
                // error handling 
        }
	go func(endpointNsName string,endpointNSHandle netns.NSHandle) {
		<-ctx.Done()
                 _ = endpointNSHandle.Close()
		_ = netns.DeleteNamed(endpointNsName)
	}(endpointNSName)

and something analogous for the newKernelVerifiableClient.

netns.Set(rootNSHandle) sets us back to the root netns.

runtime.LockOSThread() locks us to a single thread, so that all the statements in this function execute on that thread. This is important because we want to make sure we call netns.Set(rootNSHandle) on the same thread we called netns.NewNamed(...)

Questions?

[NikitaSkrynnik]

@edwarnicke Ok, I understand it now. Thanks :)

[denis-tingaikin]

Fixed in #410