privs) may get in the way if you try to use a different user than what it is running as. try making that root
<kjackal> jdstrand: the problem is that the manifests I apply are not mine
<kjackal> jdstrand: I am deploying the linkerd manifests. If they fail out of the box they will fail from anyone
<jdstrand> joedborg: are you using linkerd? have you seen/fixed kjackal's denial in kubernetes-worker?
<roadmr> linkerd sounds like a startup's name (linkerd.io! we link all your links!)
<joedborg> jdstrand: i'm not using linkered.  kjackal sent me some last week which one in particular?
<jdstrand> joedborg: the one from 30 minutes ago
<jdstrand> (in this channel)
 * joedborg found it
<jdstrand> kjackal: nnp presents a number of challenges
<kjackal> joedborg: these are the instructions for deploying linkerd https://linkerd.io/2/getting-started/
<roadmr> I was just joking about linkerd.io :(
<jdstrand> roadmr: clearly not ;)
<roadmr> well it's like "I was just joking about Donald Trump being president" :(
<joedborg> jdstrand: kjackal: Ah, no i haven't, but this may be where k8s-worker and microk0s diverge; microk8s runs a lot of infra outside of k8s, where as k8s-worker runs it inside, so there will be differences like this (where the paths are different, for example)
<joedborg> thanks kjackal, I'll test it on my local cluster
<jdstrand> joedborg: that's fine, thanks
<kjackal> joedborg: jdstrand, do you think we could say that "certain workloads will not run on strictly confined setup" ?
<jdstrand> kjackal: have you tried to use a layout for /usr/local/bin?
<jdstrand> kjackal: it isn't in the current snap.yaml
<jdstrand> kjackal: ala https://github.com/charmed-kubernetes/snap-kubernetes-worker/blob/master/snap/snapcraft.yaml
<kjackal> jdstrand:  I can add it now
<jdstrand> kjackal: I would like to better understand what is happening before saying that (re certain workloads)
<joedborg> jdstrand kjackal I think it's possible to run all workloads under strict confinement, but that it hignes on getting runc to use chroot, rat