Currently, there are three ways of interacting with network namespaces around the codebase:
- direct use of
vishvananda/netns
cilium/cilium/pkg/netns: shells out to ip netns {del,add} ... and provides some convenience features on topcontainernetworking/plugins/pkg/ns: largely overlaps with vishvananda/netns
Ideally, we would bring this down to one package with a focused API that suits our needs and safety requirements. We could likely repurpose the existing pkg/netns and copy or reimplement the bits we need from the other two, since the OS interactions needed for netns creation are fairly limited.
This issue is for implementing such an API and performing a cross-cutting refactor throughout the codebase and test suite.
Observation: netns.ReplaceNetNSWithName() is used all over. It simultaneously creates and pins a new netns to nsfs, since it invokes the standalone process ip netns add ... under the hood. Pinning is unnecessary in 99% of cases. Creating a new netns should return an object that exposes a .Pin() method to do this explicitly when needed. (e.g. a testutils package could make good use of this to allow entering the netns for debugging)
Currently, there are three ways of interacting with network namespaces around the codebase:
vishvananda/netnscilium/cilium/pkg/netns: shells out toip netns {del,add} ...and provides some convenience features on topcontainernetworking/plugins/pkg/ns: largely overlaps withvishvananda/netnsIdeally, we would bring this down to one package with a focused API that suits our needs and safety requirements. We could likely repurpose the existing pkg/netns and copy or reimplement the bits we need from the other two, since the OS interactions needed for netns creation are fairly limited.
This issue is for implementing such an API and performing a cross-cutting refactor throughout the codebase and test suite.
Observation:
netns.ReplaceNetNSWithName()is used all over. It simultaneously creates and pins a new netns to nsfs, since it invokes the standalone processip netns add ...under the hood. Pinning is unnecessary in 99% of cases. Creating a new netns should return an object that exposes a.Pin()method to do this explicitly when needed. (e.g. a testutils package could make good use of this to allow entering the netns for debugging)