Add container environment variables supported by official Plex docker image

[runecalico]

I added support for a number of environment variables supported by the latest official plex container. I added them as optional, so if not specified would not be added or have a default, and added them explicitly. It looked like the current coding pattern was to specify the env options explicitly vs use a generic "pass any env to the container" method.

Thanks for the hard work in creating the helm chart in the first place, as well as the transcoder.

[runecalico]

I have zero go coding skills, but I expect that if the primary container has the PLEX_UID and PLEX_GID environment variables set, that the transcoder pod would need to also use those UID/GIDs?

[onedr0p]

I wouldn't use underscores in the charts values name, use camelCase instead.

[runecalico]

DONE. Is that a Style decision or is there a technical reason to use CamelCase over underscores. I don't personally mind either way, but I haven't much exposure to helm chart best practices or style guides..

[onedr0p]

Every chart I've seen is camelCase.

[wrender]

Thanks for this helm chart. It is awesome. Maybe add these while you are at it? NVIDIA_VISIBLE_DEVICES=all NVIDIA_DRIVER_CAPABILITIES=compute,video,utility CUDA_DRIVER_CAPABILITIES=compute,video,utility

[runecalico]

@wrender - If this get's approved, I have another change waiting that will allow for arbitrary environment variables to be passed to the deployment, so in theory that change would allow for those variables as well as anything else you want. I don't recall seeing those as being part of the official plex docker image, and adding support for that was my focus on this PR. Additionally I have another pending change that builds on the arbitrary env's to allow you to "set" preferences using env variables, effectively allowing you to update your preferences.xml using env values at boot.

[runecalico]

@onedr0p - Is there a way to do some kind of multi-stage PR? I wanted to submit the PR's in somewhat digestible chunks, but it doesn't look like I can really do that from my fork, or perhaps it's the way I'm doing it? As I have a few additional things to add to the helm chart .. I saw that munnez doesn't have the time to update code, I am hoping however that PR's can still be looked at/approved in a timely fashion.

[onedr0p]

I'm not a maintainer on this project. I would lump them into one PR unless you want to do individual ones.

However, there is a new chart made by billimek below. This one has removed the broken kube-plex feature and focuses more on running a single container of Plex rather than scaling it. I am a maintainer there and your PRs are welcome.

https://github.com/billimek/billimek-charts/tree/master/charts/plex

[runecalico]

And your answer is basically what I was afraid of, in that maintenance of the entire repo is effectively in "mostly dead" mode, which pretty much was making me thinking about just maintaining my own helm chart ... Bleh..

[wrender]

That is unfortunate if the project maintainers aren't responding. I don't think you going off and doing your own thing really helps the community though...

[onedr0p]

@wrender there isn't much documentation on kube-plex or anyone who has stepped into do the work to support it. There also hasn't been any commits to the Go code in over 2 years. We've been trying to maintain the chart here, but it's at the mercy of the maintainers to except PRs, which often times is pretty slow at accepting. I am not complaining, I get people are busy with their lives. I am just saying maintaining the chart elsewhere is probably a wise idea, and why probably why @billimek chose to do it.

[wrender]

Is it possible to reach out to the maintainer to get admin access to the project?

[onedr0p]

Open an issue and ask.

[runecalico]

I've started to add my work to the Billimek chart, while it does mean no transcoder fun .. at least the chart get's updated :)

[simplyzee]

Hi all

Thanks for opening up another PR - I have spoken to @munnerz in regards to some of the outstanding PRs that need merging. We came up with the idea of moving kube-plex potentially into its own organization / for someone to adopt. In some cases, this would mean more people can then commit/review and maintain the repository then. I'd like to think we can focus on fixing some of the problems with the transcoder pod as I feel that is the most important feature of this repository considering the capabilities it can do.

There are improvements to be made... From having an environment that allows us to test PRs and deployments all the way to testing the transcoder mechanism. I've already started looking into addressing the transcoder issues in some of my spare time but I'd like to think others are also looking into this. I'm also limited in some regards being a contributor. Feel free to reach out to me if you like on the Kubernetes Slack - https://kubernetes.slack.com/archives/D6F1JHSL9

Thanks