Supply container hostname in CNI_ARGS

[theodiem]

What is the problem you're trying to solve

When running containers with ipam: { "type": "dhcp" } , the dhcp request have a empty hostname. Makes life painful when using dhcp to find out on DHCP server side which container have that lease.

Describe the solution you'd like

the "dhcp" type already have a mechanism to send information in the DHCP request:

provide (dict, optional): Options providing to DHCP server when acquire leases. option (string, optional): String or number representation of the DHCP option. value (string, optional): String representation of the value. Directly sent to server. fromArg (string, optional): Get value from CNI_ARGS by given argument name.

(https://www.cni.dev/plugins/current/ipam/dhcp/)

Thus supplying the container hostname in a given key under CNI_ARGS would solve the issue.

Additional context

Just for information, podman supplies the following CNI_ARGS on my tests: IgnoreUnknown=1;K8S_POD_NAME=elastic_wilbur

I can use the following configuration for my ipam:

...
"type": "dhcp",
"provide": [
  {
    "option": "host-name",
    "fromArg": "K8S_POD_NAME"
  }
]
...

Also, If there's no option supplied, the value doesn't get overriden (on my tests, CNI v1.1.1) . For example:

...
"type": "dhcp",
"provide": [
  {
    "option": "host-name",
    "value": "foo"
  },
  {
    "option": "host-name",
    "fromArg": "K8S_POD_NAME"
  }
]
...

Will sent the DHCP option "host-name" with value foo when K8S_POD_NAME is not present on CNI_ARGS. This way one can have a default value for a given option (useful for vendor-class-identifier). So anything as key could be used .. (i.e.: NERDCTL_HOSTNAME, etc.). Logic of which key goes where would stay in the ipam config.

[junnplus]

Yes, the DHCP option is not supported now, a simple way is that you can directly modify the CNI config file in /etc/cni/net.d/.

[theodiem]

Yes, the DHCP option is not supported now, a simple way is that you can directly modify the CNI config file in /etc/cni/net.d/.

That's the thing, I'm already using it through containerd config, so it works. It is just that there's no way for the CNI to know what is the container name/hostname (just the container UID, which is not useful) to pass it to dhcp client. This is already achieved, using same CNI config in podman, by supplying CNI_ARGS=K8S_POD_NAME=elastic_wilbur (for example) to the CNI.

Same could be done with nerdctl, for example supplying CNI_ARGS=NERDCTL_CONTAINER=elastic_wilbur to the CNI. This will be passed to the dhcp portion which, as described before, can be used as dhcp identifier when acquiring a lease.

Without nerdctl suplying this information via CNI_ARGS to the CNI, even if I create my own CNI and put in the begining of the CNI chain to pre-process information, I can only extract the container ID and the namespace name, not the container name and/or the container hostname.