Define Linux Network Devices #1271
Conversation
The proposed "netdevices" field provides a declarative way to specify which host network devices should be moved into a container's network namespace. This approach is similar than the existing "devices" field used for block devices but uses a dictionary keyed by the interface name instead. The proposed scheme is based on the existing representation of network device by the `struct net_device` https://docs.kernel.org/networking/netdevices.html. This proposal focuses solely on moving existing network devices into the container namespace. It does not cover the complexities of network configuration or network interface creation, emphasizing the separation of device management and network configuration. Signed-off-by: Antonio Ojea <[email protected]>
aojea
requested review from
AkihiroSuda,
crosbymichael,
cyphar,
dqminh,
giuseppe,
hqhq,
kolyshkin,
mrunalp,
thaJeztah,
tianon and
utam0k
as code owners
|
/assign @samuelkarp |
|
|
||
| **`netdevices`** (object, OPTIONAL) set of network devices that MUST be available in the container. The runtime MAY supply them however it likes. | ||
|
|
||
| The name of the network device is the entry key. |
There was a problem hiding this comment.
Does the map order matter? If so, implementation can be complicated for Go
There was a problem hiding this comment.
the linux kernel guarantees the uniqueness of the name in the runtime namespace, so a set is ok. Order is not important , each network device should be independent of each other ...
There was a problem hiding this comment.
Should we recommend a runtime performs a uniqueness check as well?
There was a problem hiding this comment.
Uniqueness inside container should be checked, e.g. that rename operation was successful
Signed-off-by: Antonio Ojea <[email protected]>
|
https://github.com/opencontainers/runtime-spec/blob/main/features.md should be updated too |
Signed-off-by: Antonio Ojea <[email protected]>
aojea
force-pushed
the
network-devices
branch
from
931e8b8
to
51e5104
Compare
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
aojea
force-pushed
the
network-devices
branch
from
51e5104
to
3a666eb
Compare
updated and addressed the comments |
|
|
||
| **`netdevices`** (object, OPTIONAL) set of network devices that MUST be available in the container. The runtime MAY supply them however it likes. | ||
|
|
||
| The name of the network device is the entry key. |
There was a problem hiding this comment.
Should we recommend a runtime performs a uniqueness check as well?
| @@ -294,4 +300,4 @@ | |||
| } | |||
| } | |||
| } | |||
| } | |||
| } | |||
There was a problem hiding this comment.
nit: newline missing at the end
| @@ -349,4 +366,4 @@ | |||
| ] | |||
| } | |||
| } | |||
| } | |||
| } | |||
There was a problem hiding this comment.
nit: newline missing at the end
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
nit: newline missing at the end
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
nit: newline missing at the end
|
AI @aojea (document the cleanup and destroy of the network interfaces) |
|
|
||
| ```json | ||
|
|
||
| "netDevices": [ |
There was a problem hiding this comment.
In this and the next example netDevices looks like "array of objects" rather than "object" as specified.
|
From the in-person discussion today:
|
|
|
||
| This schema focuses solely on moving existing network devices identified by name into the container namespace. It does not cover the complexities of network device creation or network configuration, such as IP address assignment, routing, and DNS setup. | ||
|
|
||
| **`netDevices`** (object, OPTIONAL) set of network devices that MUST be available in the container. The runtime is responsible for providing these devices; the underlying mechanism is implementation-defined. |
There was a problem hiding this comment.
This spec said "MUST" but, I think it can't do it in the rootless container because the rootless container doesn't have CAP_NET_ADMIN, right?
There was a problem hiding this comment.
I'm not sure we should take care of the rootless container.
There was a problem hiding this comment.
Could be an error in the case of a rootless container, if the runtime is not able to satisfy the MUST condition.
There was a problem hiding this comment.
Could be an error in the case of a rootless container, if the runtime is not able to satisfy the MUST condition.
+1 but It'd be better to clarify it in the spec.
| "name": "container_eth0" | ||
| }, | ||
| "ens4": { | ||
| "address": "10.0.0.10", |
There was a problem hiding this comment.
good and bad examples with IPv6 address might be good to add.
|
|
||
| ### Example | ||
|
|
||
| #### Moving a device with a renamed interface inside the container: |
There was a problem hiding this comment.
Why do we need to take care of the renaming case?
There was a problem hiding this comment.
because the name is unique, and the container already will have a network interface attached by the network configuration operation (CNI, libnetwork, netvark, ...) so this offers the capability to the user to avoid this collision
The proposed "netdevices" field provides a declarative way to specify which host network devices should be moved into a container's network namespace.
This approach is similar than the existing "devices" field used for block devices but uses a dictionary keyed by the interface name instead.
The proposed scheme is based on the existing representation of network device by the
struct net_devicehttps://docs.kernel.org/networking/netdevices.html.
This proposal focuses solely on moving existing network devices into the container namespace. It does not cover the complexities of network configuration or network interface creation, emphasizing the separation of device management and network configuration.
Fixes: #1239