[Feature request]Include an additional field in Result struct, analogous to `args` in the config struct.

[amshinde]

This will allow plugins to return arbitrary data that is specific to the plugin. I am currently looking at a OVS-DPDK plugin, that would create vhost-user sockets for virtualized containers. For this to work, the runtime should be able to get the path of the socket created by the plugin. To accommodate such use-cases, it will be useful to create an additional field+interface for the plugin to return additional data.

This has been discussed previously here:
#513 (comment)

[amshinde]

cc @rosenhouse

[amshinde]

Any feedback on this? I am willing to work on this if the maintainers agree on this feature.

[jellonek]

@dcbw @squeed ping. WDYT about that?

[amshinde]

Any feedback on this @rosenhouse @dcbw @squeed ?

[squeed]

In general, we've been reluctant to consider this in the past, since it decreases the value of CNI as a specification. If there's an attribute that it makes sense to export, then it should be part of the spec.

However, this sort of rigid viewpoint is easy to dictate from up on high.

What sort of attributes were you thinking?

[amshinde]

@squeed I am currently looking at a CNI plugin that uses Open vSwitch. This plugin would return a vhost-user interface for use with a hypervisor-based containers. The vhost-user socket is a path on the file-system, that will be used as a network interface by the container.

So, essentially, the plugin needs to send this path as an additional attribute vhost_user_path.

[dcbw]

@amshinde what would the runtime do with the vhost-user socket, and how would it pass that to the workload to enable the workload to load the DPDK libraries and start passing traffic on the VF?

[amshinde]

@dcbw The runtime would check for the vhost-user-path attribute and pass this socket to our hypervisor based container (as a backend for virtio-net) The container would then see this as just another network interface. The socket just acts as shared memory based interface.
The container workload does not need to be customized in any way. The loading of the the DPDK libraries on the host is upto the CNI plugin itself.

[kmala]

Any update on this? This feature will be help especially in the scenario's of chained plugins where one plugin wan't to pass some data to the next one.

[squeed]

I have a plan for this: allow plugins to inject additional capabilityArgs to plugins down the chain. Thoughts? I'm going to get someone to write it up shortly.

[squeed]

@dougbtv has agreed to take some time and prepare a SPEC.md PR for this (in due time).

[oilbeater]

Any update on this? We are still struggling to find a way to pass extra data from one plugin to another.

[dcbw]

@oilbeater @Colstuwjx is the main use-case still vhost-user? Can you elaborate on the control flow here? eg plugin A adds the vhost-user-path + data to capabilityArgs and then what plugin consumes that item later in the chain? Or is it just to preserve the path in the cached result for DEL? Or is it just to return some random data to the runtime that would use it somehow?