cni
cni copied to clipboard
containernetworking
skel support context
I think skel should support context, because CNI plugin may use invoke functions like DelegateAdd or ExecPluginWithResult, in this situation, CNI plugin should decide the default context and pass it to invoke functions.
ref to https://github.com/containernetworking/plugins/pull/346
@bboreham @dcbw @squeed sorry for disturbing, do you have some suggestions?
@mars1024 we really think this value should come from the runtime; but in reality what we discussed is somewhat different than this:
libcni should handle timeouts and when the timeout is triggered libcni should SIGTERM all the plugins, wait a short amount of time for plugins to clean up, and then SIGKILL them. This means plugins don't have to implement chained context logic of any kind, but (similar to upstart/systemd/etc) have a chance to clean up lockfiles or other resources before they are done.
@mars1024 we really think this value should come from the runtime; but in reality what we discussed is somewhat different than this:
libcni should handle timeouts and when the timeout is triggered libcni should SIGTERM all the plugins, wait a short amount of time for plugins to clean up, and then SIGKILL them. This means plugins don't have to implement chained context logic of any kind, but (similar to upstart/systemd/etc) have a chance to clean up lockfiles or other resources before they are done.
Yes, I agree on the "SIGTERM and SIGKILL" way, but this does not mean that plugins has no rely on context, instead, plugins should have a signal handler to receive the signals and a parent context based on the signals. I think these changes should be done in skel.