[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?

[Colstuwjx]

It's similar to this, but not the same one.

In my case, I just have two plugins as a chain, and I want the upstream plugin could return a result with some extra vars, if the extra vars are set, the downstream plugin should do some tasks, such as setting up the firewall rules and network policies, but it's optional, if no extra vars passed, the downstream plugin may set the defaults.

[oilbeater]

In my case, we want to build a cluster wide IPAM to different CNI and the IPAM can manage some plugin specific options like vlanID, paraentNic, deviceID etc. In that way, the main plugin (maybe a modified vlan, macvlan or host-device) can use the extra options to config the nic. Otherwise the main plugins have to use a static config or request another configserver to get the options.

[bboreham]

I'd like to know why it is called capabilityArgs. Does it relate to "capabilities" described in CONVENTIONS.md?
And why "args" when it is part of the result?

[Colstuwjx]

Yes, I also don't like the word capabilityArgs, maybe something like Args should be better. For me and @oilbeater , both of cases are, we could NOT pass extra args inside IPAM plugin result, since its type didn't support carry extra args, that's the reason for adding this "args".

Thanks.

[mars1024]

I have to say that Result is just result, even some data inside Result will be used in other plugins, but it should not be called as args.

What we are talking is actually the extendablility of Result, should it carry user-defined datas, just like metadata.annotations in Pod.

[amshinde]

Agree with @mars1024. Its been a while since I created this feature request, but what I had in mind was the ability for a plugin to return additional set of data in the Result structure, essentially being able to extend the Result structure.

[Colstuwjx]

Yes, whatever the terminology is, we just want to have this extendablility .

[MikeZappa87]

@amshinde hello we were just talking about this as apart of #1050 does this help?