CFP: do we need an escape-valve from GC?

[squeed]

If there are multiple runtimes using the same network configuration, then no one runtime knows the set of valid attachments. Thus, a GC call may contain an incomplete set of valid attachments, and in-use resources may get cleaned up. Not good.

We should provide administrators a way to disable GC for a given network configuration, if they know that it will be used in a manner not amenable to GC. Much the way disableCheck is implemented.

[s1061123]

I come up with alternative way to escape GC from container runtime side. Currently libcni does not have explicit GC invocation because libcni expects that container runtime should invoke GC function GCNetworkList as they want to (e.g. periodically once a hour, or on-demand) and CNI Spec does not have any requirements/recommendations for GC, to container runtime.

So once container runtime implements (i.e. calls) GC, they may introduce config options, such as GC interval or something. I just expect that container runtime config also introduce disableGC in each container runtime config when container runtime utilizes libcni's GC.