This message was deleted.

=> #rancher-desktop It doesn't look like a known issue, atleast a quick search on GitHub didn't return anything. yes, Jan might have some insights to share. I filed a GitHub issue for now. Thanks for reporting the behavior though.

Thank you for a quick reply, @rapid-eye-50641! I also copied the same message to Linkerd Slack channel. If I hear from them, I'll let you guys know

/opt/cni/bin/ is a pretty common path for plugins, but it’s not uncommon for some things to put them in different places. K3s/RKE2 also have custom bin paths.

Turns out, linkerd allows to control where the binary goes:

linkerd install-cni --dest-cni-bin-dir /usr/libexec/cni/

will place the executable where Rancher Desktop expects it to be. While this resolves my immediate issue, it leaves some gaps: 1. How does a new user, like myself, knows where plugin executables should go, without running into a problem first? 2. What if the Rancher Desktop plugin location changes? Any automation and/instructions pointing to an old location will stop working #1 falls under "you don't know what you don't know" situation, understandably. #2 hopefully never happens, but things will always change. With linkerd #2 becomes worse - if Rancher Desktop changes the plugin location - say to the common path, per @creamy-pencil-82913 comment - linkerd will stop working after upgrade that changes the location, which might take a few hours to troubleshoot. Given that linkerd provides a lot of very attractive features, many of which will be used by a project, it would be a disaster. I'm wondering if there any way to deal with such potential issues.

RD clusters aren’t really meant to be for production use - they’re meant for development and are essentially disposable. Would it be a disaster if you had to change the linkerd config? You’ll need to reinstall it every time anyway whenever you reset the cluster in RD.

RD clusters aren’t really meant to be for production use

We're aware

Would it be a disaster

Loss of productivity and delayed releases come to mind. With linkerd, broken CNI plugin might require resetting the cluster and starting from scratch. More reasons to automate things, of course. To make it clear, I'm not blaming anyone or any product, just looking for a solution. I want RD to be successful - after Docker k8s support disaster, RD is a breath of a fresh air. I'm a big proponent of RD in my company and want it to just work. Otherwise people start using "dev clusters" which are shared, thus no one really controls them and in general they're even bigger disaster.

@broad-train-31975 I've copied your feedback to linkerd-cni requires copying `linkerd-cni` plugin from /opt/cni/bin/ to /usr/libexec/cni/ · Issue #6170. Please continue any further discussion in that Github ticket (preferred), or start a new thread in the #rancher-desktop channel!

Hi @fast-garage-66093 I'll be watching the ticket. I don't think RD can (or should) do anything about it; just maybe leave a note for Linkerd users to add a flag and the location to linkers cni install command. So that people running into this issue can google it out and have a solution.