go-cni

go-cni copied to clipboard

Need to decide when to update CNI and establish a cadence process.

• [ ] coordinate updating cni and plugins across the stack #56

• [ ] evaluate new cni cache config apis

What is new cni cache config apis here? :)

New stuff to look at for cni https://github.com/containernetworking/cni/pull/661 Adds an api for:

"Cache the config JSON, CNI_ARGs, and CapabilityArgs on ADD operations, and remove them on DEL. This allows runtimes to retrieve the cached information to ensure that the pod is given the same config and options on DEL as it was given on ADD." "So @squeed and I talked about it for a while, and decided that yes there are use-cases for changing parts of a given network config underneath the container, but not for switching the network config out entirely. So much like @mars1024 is saying, a delete operation should probably only check network name (and perhaps plugin type) from the config its sending and make sure those match." "I think the config caching that this PR does is probably OK, since all it does is allow the runtime (dockershim, crio, etc) to retrieve that config. Then the runtime can make the decision about whether to use an existing updated configuration that it already knows about, or if that's no longer valid (eg old config deleted entirely) it could use the cached config." "Does that sound OK to everyone? eg libcni only does the storage/retrieval, while the runtime itself can make policy decisions about how to handle config changes."

new stuff for plugins: Check support https://github.com/containernetworking/plugins/pull/264

New plugins: bandwidth - limit incoming and outgoing bandwidth (#96), (#138). firewall - add containers to firewall rules (#290). sbr - convert container routes to source-based routes (#212). static - assign a fixed IP address (#136), (#165). win-bridge, win-overlay: Windows plugins (#193), (#215).