Ref http://kubernetes.io/docs/admin/network-plugins/
The --network-plugin-dir means two things under different settings of the --network-plugin:
- If
--network-plugin=cni, the --network-plugin-dir is where the CNI config locates.
- If
--network-plugin=kubenet, the --network-plugin-dir is where the plugin binaries can be found in addition to the default one (/opt/cni/bin).
IMO that having the flag to mix up the two related things makes me feel confused, can we split into two flags, one is for binary, one is for config files?
I understand that when using --network-plugin=kubenet, there's no need for the config dir, but I don't think that's sufficient we override the flag with another meaning...
Another benefits for having two flags is now with --network-plugin=cni, we will be able to specify the plugin binary search path other than /opt/cni/bin/.
cc @kubernetes/sig-network
Ref http://kubernetes.io/docs/admin/network-plugins/
The
--network-plugin-dirmeans two things under different settings of the--network-plugin:--network-plugin=cni, the--network-plugin-diris where the CNI config locates.--network-plugin=kubenet, the--network-plugin-diris where the plugin binaries can be found in addition to the default one (/opt/cni/bin).IMO that having the flag to mix up the two related things makes me feel confused, can we split into two flags, one is for binary, one is for config files?
I understand that when using
--network-plugin=kubenet, there's no need for the config dir, but I don't think that's sufficient we override the flag with another meaning...Another benefits for having two flags is now with
--network-plugin=cni, we will be able to specify the plugin binary search path other than/opt/cni/bin/.cc @kubernetes/sig-network