Hi, I see that the update is already been accepted by openSUSE:Factory so please bear with me that I'm quite late. I'm not sure If this kind of adaptions to the package are the right way to solve the configuration problems, so I would propose an additional change for the next upcoming major version of CRI-O: As far as I understood was the problem that CRI-O does not start if there is a CNI plugin directory configured which does not exist. Other projects like Cilium would run as DeamonSets on Kubernetes where CRI-O surely has to be started before. To fix this, I changed the upstream behavior for the CNI plugin directory validation that not existing directories will be created automatically by CRI-O [1]. This makes the following lines in the spec obsolete for the next major (v1.15.0) release: ``` %post %service_add_post %{name_source1} # This is the additional directory where cri-o is going to look up for CNI # plugins installed by DaemonSets running on Kubernetes (i.e. Cilium). mkdir -p /opt/cni/bin ``` If you're fine with that I will keep track of that proposal. Nevertheless, we would still keep the "/opt/cni/bin" directory in the CRI-O configuration: ``` plugin_dir = ["/usr/lib/cni", "/opt/cni/bin"] ``` If the CRI-O configuration (in the future) is not flexible enough for our needs, we could consider using the `crio config` subcommand with different arguments for different distributions. All the best, Sascha [1] https://github.com/cri-o/cri-o/pull/2284 On 4/18/19 2:37 PM, Thorsten Kukuk wrote:
Hi,
On Thu, Apr 18, Michal Rostecki wrote:
1. Changing the cni-bin-dir parameter for Kubelet to `/usr/lib/cni,/opt/cni/bin` to support both CNI plugins installed on host and those installed dynamically.
As /opt/cni/bin is the upstream default and mentioned everywhere in the documentation, we should add that if cni-bin-dir allows a comma seperated list of directories. Everything else will only be confusing and limited the usage of third party solutions.
2. Adding cilium-cni package to patterns-containers.
devel:kubic/cilium contains for cilimum-cni: Requires: cilium
That would mean, we pull in a huge amount of code. Is this requires really correct? I cannot imagine if I look at the cilium-cni package. If yes, adding cilium-cni is a no-go due to the size. If no, remove that Requires and add additional cilium-cni to the container patterns.
Thorsten
-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org