Chart deployment fails if existing claim is same for all data, config and transcode

[prasannjeet]

I had a common PVC for all data, config and transcode with their own subPath, /data, /config, and /transcode, respectively.

But in this case the pod never initialises and fails to mount PVC's.

In this case, when I manually edited the deployment to remove the two extra volumeMounts, and use the same PVC for all the three volumes, it works without an issue.

Perhaps this could be fixed in helm, such that if pvc name is the same, not to create separate volumeMounts in the deployment, and re-use the existing mount.

[ressu]

I think I understand what you mean, but I have some followup questions. Even though it might not be easily fixable in the helm chart.

Looking at the way how the helm chart sets up the mounts, it will create multiple volumeMounts in the deployment:

https://github.com/ressu/kube-plex/blob/040f189ef10f1cf58e42d37d7678b6ab3935a7eb/charts/kube-plex/templates/deployment.yaml#L138-L159

and

https://github.com/ressu/kube-plex/blob/040f189ef10f1cf58e42d37d7678b6ab3935a7eb/charts/kube-plex/templates/deployment.yaml#L166-L200

The issue with fixing this is that the templating language is very simple. If we wanted to remove the other volumes the mount names would need to be changed in volumeMounts and deduped in volumes. So this isn't all that trivial to fix.

That all being said. If you are seeing issues with the double volumeMounts in your deployment, there might be another issue you're not noticing. The transcoding pod will try to get volume mounts from the main plex container. This means that some of the PVCs are carried over to the transcoding pods. If you have issues double mounting (which usually is transparent within a single node) in the plex deployment, I would expect to see the same issues when starting the kube-plex transcoders.

Edit: forgot the questions!

• Does a transcoding pod launch correctly with your setuo
• Do you share the data volume to the transcoder or is there something else that holds your media?

[prasannjeet]

Thanks for your response. While I don't understand a lot about the helm templating, I do see that the volumeMounts' names are hardcoded, viz. data, config and transcode. (Line 139, 144, 149). Like you said, yes, it doesn't look very trivial to fix.

Right now, the volume part in my deployment.yaml looks something like this:

        volumeMounts:
        - mountPath: /data
          name: plex-volume
          subPath: data
        - mountPath: /config
          name: plex-volume
          subPath: config
        - mountPath: /transcode
          name: plex-volume
          subPath: transcode
        - mountPath: /shared
          name: shared

      volumes:
      - name: plex-volume
        persistentVolumeClaim:
          claimName: plex-volume-claim
      - emptyDir: {}
        name: shared

While I don't exactly remember what was the error, I think it probably was something in the lines of failed to mount volume.... I use a ReadWriteMany NFS volume in this case. To answer your questions:

1. Yes, the transcoding pod launches correctly, and I could see the \transcode\Transcode\Sessions\some-transcode-folder being created with the parts when I try to play a video.
2. I couldn't understand what you mean by sharing data volume to transcoder, but I do not modify anything else other than the configuration that I shared. My Persistent Volume is just one folder called Plex, with three sub-folders, config, data, and transcode. The data folder contains all of my media.

[ressu]

Interesting. The fact that you're using NFS should make this a very straightforward thing. I wonder what caused the initial storage mount to fail. Also the fact that you are using NFS answers pretty much all of my questions in one go 😄

I'll leave the issue open for visibility and to invite someone to fix this, but I don't think I'll be investing any time in fixing this myself. In general I would recommend that you look at the kustomize based templates as they allow you to customize everything as much as you want, but require you to manage your deployment in a slightly different way.

Also as a sidenote, have you experienced issues with Plex corrupting configuration when using NFS to store the config volume? There used to be an issue which caused some lockups and corruption in corner cases. I haven't been paying attention to that issue lately so I'm not sure if it's been fixed upstream.

[lknite]

I'd recommend using taints and tolerances to target a single node, and use a localshare pvc rather than nfs... to eliminate a variable until you get things working. I used nfs before and had a great deal of issues, though I've seen nfs on top of vmware, nfs on top of cephfs work, just standing up my own nfs server never did work.

[Xarin]

I've nailed the NFS issue down to plex's database so I added another volume that I run as a longhorn pvc.

    - name: db
      mountPath: /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases
    {{- if .Values.persistence.db.subPath }}
      subPath: {{ .Values.persistence.db.subPath }}
    {{ end }}

Everything else should be able to sit on top of NFS without issues.