Changes from PR #225 break existing workflow

[bezerker]

Hi all,

Looks like the changes in https://github.com/billimek/billimek-charts/pull/225 break my setup. Historically, I have even prior to kubernetes used downloads on separate storage devices than my media. The changes in the charts from #225 seemingly break this workflow. While it is correct that data is copied until it's cleaned, this may be intentional to many users.

(Example, my downloads go to a fast ssd backed pvc for checking and unrarring, while media is moved to slower spinners in a large pool once complete.

Can we add support for this back in @WojoInc or @billimek ? Happy to fork and try to support both worlds, but as of now, existing charts will break for my setup with this result.

[billimek]

Hi @bezerker, is it possible for you to leverage the extraExistingClaimMounts setting to achieve having separate volumes for downloads and media/tv ?

When we originally discussed introducing the breaking change, it seemed like the default behavior of having downloads & media be on the same volume was preferable to having them separate due to the performance implications.

@abel408 or @WojoInc any thoughts about this to contribute?

[technicalhydrochicken]

Just to chime in a little, I've got the same workflow as @bezerker. I ended up using extraExistingClaimMounts to successfully replicate the old behavior, it worked well. Ended up with an extra stanza like:

        extraExistingClaimMounts:
          - name: download-scratch
            mountPath: /downloads
            existingClaim: download-scratch

Then adjusted the paths everywhere in the web-ui (all hail mass editor) and everything worked as before

[bezerker]

I believe I should be able to do this. I'll test this tonight and verify.

[bezerker]

Finally got around to testing this. This seems to work fine. Thanks for the help guys!