Provide namespace / job / group / alloc_id to CNI plugins

[apollo13]

To make it easier to write CNI plugins it would be great if nomad could provide namespace / job / group / alloc_id via CNI_ARGS to CNI plugins. While it is already possible to use the alloc id (but only when setting the namespace to '*') to query the nomad API and request this information, it would reduce the number of moving parts massively.

The namespace, job and group names are rather important if the CNI provides network policies, which could be nicely written using that information.

Kubernetes already provides the pod name and namespace via CNI_ARGS, so it is not like we are inventing something new here :) Also nomad allows to set similar information for docker containers which makes it easier for 3rd party tooling to do something with it -- why not also make it nicer for CNI. The possibilities are endless, for instance I could use it to update a DNS Server with the alloc ips etc… The changes required in nomad are probably minimal, the extra bytes in the CNI_ARGS will most certainly not hurt and it might make things easier for people trying to do something with CNI.

/cc @tgross

[tgross]

I asked @apollo13 to open this issue from another discussion we were having. I think this is a great idea but because it represents a new "interface" to ecosystem projects I wanted to get a dialog going with folks whom I know are looking at / have been looking at things like virtual machine networking, CNI, task networking, etc. So I'm going to @-mention a bunch of folks and then leave y'all to chat 😁 cc @rboyer @jrasell @Juanadelacuesta @gulducat

[deverton-godaddy]

More information being available during the CNI ADD call would definitely help simplify scripts that try and wrap CNI implementations to help bridge Nomad information in. For example, #12120 (comment) could be simpler with the task group name and namespace were available as environment variables.

[apollo13]

@tgross People seem to be generally in favor (at least not opposed). Any chance of moving that forward?

[tgross]

Seems reasonable, especially given that we now support CNI args generally so there's a place to wire that up. I'll mark this for roadmapping but it also seems like the sort of thing where a community contribution would be feasible too were one so inclined.

[apollo13]

You mean like #24319 ?