Proposal: Add metadata map field to Interface object in CNI Result

[MikeZappa87]

CNI spec should be allowed to pass arbitrary data in CNI result from the container runtime to the OCI runtime. Currently, there is an ability to influence the inputs to the CNI network configuration via runtime configuration. In a similar way, the CNI can add a metadata field to interface to pass down additional data to OCI runtime. The metadata field will be added to the Interface struct as a map[string]string and be optional. We can standardize specific keys similar to our conventions. The NRI plugin system may also benefit from this additional metadata. Our main use case for this is to support virtual runtimes and possibly advanced networking scenarios. This has been requested several times however no one has completed the work.

Current:

type Interface struct { 
    Name        string `json:"name"` 
    Mac         string `json:"mac,omitempty"` 
    Sandbox     string `json:"sandbox,omitempty"` 
} 

Proposal:

type Interface struct { 
    Name         string `json:"name"` 
    Mac          string `json:"mac,omitempty"` 
    Sandbox      string `json:"sandbox,omitempty"` 
    Metadata     map[string]string `json:"metadata,omitempty"` 
} 

Work Involved:

1. Create proposal as a Github Issue in the CNI repo
2. Create a PR for the specification updates
3. Create a PR for libcni
4. Update community plugins
5. Update go-cni/ocicni to support latest types
6. Update containerd/cri-o to use latest go-cni/ocicni

[squeed]

We've discussed interface metadata for some time; I'd like to gather some use cases before we commit to a design. I think it would work well, though. Pinging some people for suggestions:

• @maiqueb
• @mmirecki
• @dougbtv

[maiqueb]

/cc

[MikeZappa87]

@dougbtv we discussed this briefly before the holidays, do you have any thoughts?

[squeed]

First thought:

• whatever interface-level metadata we support should be defined in CONVENTIONS.md.
• Keys should be "namespaced", and the namespace cni.dev/ should be reserved.

[squeed]

If there is some consensus that this is an avenue we would like to explore, the next steps would be:

1. Identify a few actual use-cases, so we can intuit whether the proposal meets their needs
2. Start to work on a SPEC draft

[dougbtv]

In favor of moving forward on this.

I also like the idea of having namespaced keys... Would we want a namespace field for the metadata as a whole? Or mix-matched within the Metadata field, e.g. within the metadata field {my.io/foo: "bar", org.io/quux: zuuz} I guess I like the latter after typing it out.

[MikeZappa87]

If the case of a key that doesn't have cni.dev/ would libcni parse those out? Or will this be pass through?

[MikeZappa87]

@maiqueb does this help kubevirt?