node_linux_test.go currently sets up topologies like these:
All of these topologies are set up in an imperative style, using individual calls to the netlink lib to manage devices and addresses:
etc..
Instead, I propose we implement a Go package that enables a declarative style like Containerlab (not yaml, something idiomatic in Go):
To avoid a bunch of netlink.LinkByName() calls, we want to be able to extract handles to devices in a declarative way, too, much like LoadAndAssign() in ebpf-go:
This way, only one call needs to be made to obtain all handles one wants to interact with from the test.
As a first target, port some or all of the tests in node_test_linux.go to this new API to get a feel for the exact requirements.
As a knock-on effect, it will become trivial to create new tests that need an intricate network topology. By lowering the barrier and automating the boilerplate, authoring new tests will become significantly easier and more commonplace.
This issue practically depends on #27449.
node_linux_test.gocurrently sets up topologies like these:All of these topologies are set up in an imperative style, using individual calls to the netlink lib to manage devices and addresses:
Instead, I propose we implement a Go package that enables a declarative style like Containerlab (not yaml, something idiomatic in Go):
To avoid a bunch of
netlink.LinkByName()calls, we want to be able to extract handles to devices in a declarative way, too, much likeLoadAndAssign()in ebpf-go:This way, only one call needs to be made to obtain all handles one wants to interact with from the test.
As a first target, port some or all of the tests in
node_test_linux.goto this new API to get a feel for the exact requirements.As a knock-on effect, it will become trivial to create new tests that need an intricate network topology. By lowering the barrier and automating the boilerplate, authoring new tests will become significantly easier and more commonplace.
This issue practically depends on #27449.