Re: [Discuss] Seeking advice on net selftests netns naming method

[Paolo Abeni <pabeni@redhat.com>]

On Tue, 2023-11-14 at 17:55 +0800, Hangbin Liu wrote:
> Good day! Following Guillaume's suggestion, I've been working on updating all
> net self-tests to run in their respective netns. This modification allows us
> to execute all tests in parallel, potentially saving a significant amount of
> test time.
> 
> However, I've encountered a challenge while making these modifications. The
> net selftest folder contains around 80 tests (excluding the forwarding test),
> with some tests using common netns names and others using self-defined names.
> I've considered two methods to address this issue:
> 
> One approach is to retain the original names but append a unique suffix using
> $(mktemp -u XXXXXX). While this is a straightforward solution, it may not
> prevent future tests from using common names.
> 
> Another option is to establish a general netns lib. Similar to the NUM_NETIFS
> variable in the forwarding test, we could introduce a variable like NUM_NS.
> This variable would define the number of netns instances, and all tests would
> use the netns lib to set up and clean up netns accordingly. However, this
> approach might complicate test debugging, especially for tests like
> fib_nexthops.sh, which relies on clear and visually netns names
> (e.g., me/peer/remote).

I personally would like sort of both :) e.g. lib function(s) to
automatically create and dispose netns, and retain a script-
specific/related name prefix. 

The library function could optionally set  the newly created namespaces
name in global variables provided by the caller, e.g.:

# create 3 namespaces:
netns_init 3 

# create 3 namespaces and set the global variables:
# $remote, $local $me 
# to their respective names
netns_init 3 remote local me

The trick to do such assignment would be using the 'eval' statement,
something alike

netns_init()
{
	# create the netns

	shift
	while [ -n "$1" ]; do
		eval $1=$NETNS_NAMES[0]
		shift
	done
}

While at that, it would be useful to package some common helper e.g. to
wait for a (tcp) listener to be created (available) on a given port.

WDYT?

Thanks!

Paolo