containernetworking
Enhanced plugin / network lifecycle ( INIT / DEINIT / GC)
Background
CNI 1.0 has a very simple lifecycle: ADD and DELETE (and CHECK). This isn't perfect; there are some additional stages we may wish to capture.
In general, these lifecycle stages are probably per (plugin, network) pair, rather than plugin itself.
Possible new verbs:
INITIALIZE
Tell a plugin to configure a network based on some configuration.
This could involve something like setting up a bridge, adding some iptables rules, and the like.
DEINITALIZE
Tell a plugin that its services are no longer needed for a given network.
GC
Pass a plugin the entire list of known attachments. Any other attachments can be cleaned up.
I think we should move forward with GC and STATUS ASAP. There are real-world use-cases that these will fix, and soon.
I'll start drafting a spec.
GC
Pass a plugin the entire list of known attachments. Any other attachments can be cleaned up.
Maybe this should be more "SYNC", with the expectation that the plugin also checks for containers that should have been attached but aren't. (See https://issues.redhat.com/browse/RFE-2865 / https://bugzilla.redhat.com/show_bug.cgi?id=2066351 where something (NetworkManager?) is breaking a bridge CNI bridge, and they want something to be able to fix it up when that happens.)
We had a long talk about this in the latest maintainer's meeting. The conclusions:
- ocicni and, soon, libcni, will implement attachment caching
- GC() will be an API method on libcni first and foremost
- libcni should, when passed
GC([list of valid attachments]), synthesize a CNI DEL of any cached attachments not in the list - We would also like to add GC CNI verb, but implementing it in libcni first will get us 90% of what we want.
How does that sound, @henry118?
@squeed having a GC API sounds good to me. I'd also like libcni to have an API to query all known attachments (as proposed by #963). for the case of containerd's GC model, the latter makes it a lot easier.
At this point, we are working on GC for v1.1, but INIT / DEINIT have been de-scoped.
At this point, we are working on GC for v1.1, but INIT / DEINIT have been de-scoped.
Nice about the GC verb - that's a very good improvement.
Could you elaborate a bit on the INIT scenario ? How would this look like from the user's perspective ? I wonder how this looks like vs a CNI chain ...
@squeed
