Ability to map CNI networks to user-configurable interface names inside containers

[ettoredn]

/kind feature

Could you consider the ability to map networks to specific interface names inside the container? From what I can see right now every interface is simply named eth<id>.

A simple use case for this is running a DHCP client on an macvlan interface from inside the container. By mapping a network to a predictable interface name, there would be more assurance on which interface/network it is run. Moreover, this would also become handy when there is the need to bind certain services to specific networks only.

[mheon]

Can you give an example of what you would like the interfaces to be named?

[Luap99]

That should be possible with CNI but how should the UI look like? I would prefer to not have an extra cli flag.

[ettoredn]

Had a quick look at CRI-O and there already is support for it (also look around for CNI_IFNAME env).

IMO the best design would be as simple as adding the ifname key to the network .conflist.

@mheon does it matter what name I'd like to set it to? In my setup the name I'd like to have is tcloud. To be more verbose: in this setup each container is expected to have a ptp (let's name it ptp!) for egress IPv4 traffic to the internet, and a macvlan interface connected to a private IPv6 virtual network to access various services and receive HTTP requests from HAProxy.

[mheon]

Ah, so the ask is for the interface name to be user-configurable.

[Luap99]

The problem is we support n networks for a container, so CNI_IFNAME env does not work. Adding it to the conflist file is out of our control and I doubt that the CNI maintainers would like this.
I know that this is easy to set in the networking code. The problem is the frontend IMO. I just don't see a good UI at the moment.

[mheon]

We could do something similar to what we used to do for static IP and IPv6, where they're only supported with the CNI backend if you only join a single network - the user experience for that is bad, but not unusable.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mheon @Luap99 Should we mark this as being fixable in 4.0?

[Luap99]

Yes, the db changes must be done anyway. My only question is how the cli parts should look like.
Maybe we can use the same logic as slirp4netns options, e.g. --network mynet:interface_name=eth0

[mheon]

I think that's a good idea - we made them generic when we added them for this sort of eventuality.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.