Define Linux Network Devices #1271
Conversation
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
There was a problem hiding this comment.
added more text to clarify runtime checks and network devices lifecycle, PTAL
|
https://github.com/opencontainers/runtime-spec/blob/main/features.md should be updated too |
aojea
force-pushed
the
network-devices
branch
2 times, most recently
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?
|
AI @aojea (document the cleanup and destroy of the network interfaces) |
|
From the in-person discussion today:
|
config-linux.md
Outdated
|
|
||
| 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.
There was a problem hiding this comment.
added mor explanations about runtime and network devices lifecycle and runtime checks, PTAL
Pushed a new commit addressing those comments, the changelog is
|
aojea
force-pushed
the
network-devices
branch
from
5ed1640 to
d8eb25f
Compare
|
@aojea Thanks for your hard work! It looks good to me. Also, I agree that it includes 1.3.0. |
config-linux.md
Outdated
| The runtime MUST revert back the original name to guarantee the idempotence of operations, so a container that moves an interfaces and renames it can be created and destroyed multiple times with the same result. | ||
| * **`addresses`** *(array of strings, OPTIONAL)* - the IP addresses, IPv4 and or IPv6, of the device within the container in CIDR format (IP address / Prefix). All IPv4 addresses SHOULD be expressed in their decimal format, consisting of four decimal numbers separated by periods. Each number ranges from 0 to 255 and represents an octet of the address. IPv6 addresses SHOULD be represented in their canonical form as defined in RFC 5952. | ||
| The runtime MAY limit the number of addresses allowed. | ||
| The runtime MAY decide to revert back the original addreses. |
There was a problem hiding this comment.
I think we need to clarify the expected behavior or add a field to ensure consistent behavior across runtimes.
There was a problem hiding this comment.
This also depends on whether the interface will be moved back or destroyed.
What about "The runtime MAY decide to revert back the original addreses or completely remove all the existing addresses"?
|
|
||
| * **`name`** *(string, OPTIONAL)* - the name of the network device inside the container namespace. If not specified, the host name is used. The network device name is unique per network namespace, if an existing network device with the same name exists that rename operation will fail. The runtime MAY check that the name is unique before the rename operation. | ||
| The runtime MUST revert back the original name to guarantee the idempotence of operations, so a container that moves an interfaces and renames it can be created and destroyed multiple times with the same result. | ||
| * **`addresses`** *(array of strings, OPTIONAL)* - the IP addresses, IPv4 and or IPv6, of the device within the container in CIDR format (IP address / Prefix). All IPv4 addresses SHOULD be expressed in their decimal format, consisting of four decimal numbers separated by periods. Each number ranges from 0 to 255 and represents an octet of the address. IPv6 addresses SHOULD be represented in their canonical form as defined in RFC 5952. |
There was a problem hiding this comment.
Is the runtime expected to set this? It looks like it is. Let us say that in the spec.
There was a problem hiding this comment.
This is the input to the runtime, the runtime may choose how to set them meanwhile is consistent.
The context is that from kubernetes we got bitten by this, so is a recommendation because we find very hard to enforce this as input as it may break some clients , more context in https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4-addresses/
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]>
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
- Clarify network device lifecycle and runtime checks during creation and deleting of the container. - Remove mask field and instead use the Address field with CIDR annotation to allow to use it for both IPv4 or IPv6. - Add a HardwareAddress field for use cases that require to set a specific mac or infiniband address. Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Albin Kerouanton <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
- Remove reference to rootless containers, the feature flag will be used by the corredponding runtime to indicate if the feature is supported. - Clarify the runtime MUST set the interface UP when moving it to the container network namesapce - Clarify the runtime MUST revert back the original name if the interface is renamed to guarantee idempotence - Clarify the runtime MAY choose to revert the other original attributes like addresses, mtu and hardware address. Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Albin Kerouanton <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Mrunal Patel <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Mrunal Patel <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Mrunal Patel <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Co-authored-by: Mrunal Patel <[email protected]> Signed-off-by: Antonio Ojea <[email protected]> Signed-off-by: Antonio Ojea <[email protected]>
Signed-off-by: Antonio Ojea <[email protected]>
aojea
force-pushed
the
network-devices
branch
from
47c4d3c to
80e758e
Compare
|
Changelog since last review, only the part that was not clear, to decide if runtime MUST or MAY bring back the interface to the host namespace, got updated to make it MUST , since is less ambiguous and covers all use cases, more on #1271 (comment) |
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