Closed ohthehugemanatee closed 3 years ago
Considering your setup, I would almost recommend using a non-helm setup. I have my setup built using just a basic kustomize based setup which I overlay with deployment specific definitions. This gives me much better control on the final setup than the helm based templates generally do. But I digress...
One thing you can try is to define a second PVC with the same NFS endpoint. Linux shouldn't have any issues mounting the same NFS destination on a same machine. Unfortunately it does mean that you need to maintain 2 PVC definitions. In best case scenario, you might be able to use the same PV definition, but it might even require duplicating it too.
good workaround... and I've considered just adapting my currently active, non-helm plex installation to use your image with the shim. But it takes a lot of investigation to work out how the shim knows the details of how to launch the transcoder. Also, I figure the "vanilla" helm chart approach should be the best way to PoC it working before embarking on something complicated.
For now, I've just mounted my NFS root as /data , and used the config mount options to make it get a separate PVC for configuration. Good enough for now, but I hope this thread helps out future explorers. Thanks!
I just created a PR to include my kustomize based setup as an example in #18 in case you want to add feedback to it before I merge it to main
Right now each mount assumes it's the only one using that PVC. In my case, I have a PVC for my NFS filesystem.
plex
andmovies
directories are peers at the top level, so I have to mount indata
andextradata-movies
separately:The helm chart creates a deployment with two identical Volumes for
nfs-claim
, which fails. Instead, we should notice that the same claimName is specified, and only create one PV. You could maybe do this by naming the Volume after the PVC....