I currently have the TrueNAS app catalog version of Tautulli installed on my TNS box, and it’s telling me there’s an update available. However, no update has been pushed to the TrueNAS app catalog as the maintainer, onedr0p, has deprecated it from their collection as of April 14th.
Okay, I think, I’ll install the Truecharts version instead. Except that also uses onedr0p’s containerised version. onedr0p seems content to deprecate software from their collection for a variety of reasons, possibly not making them the most reliable of sources for addition in a catalog. (NB. this is no criticism of onedr0p or their project).
It’s not (yet) essential that I update this app, but I found it interesting to discover that both catalogs are using the same upstream source for their apps in this instance, and that users are now left without updates.
It seems the only option now is to go down the relatively complex route of setting up a vm with docker on it to run an up to date version of the software in.
(Before anyone helpfully suggests I take on maintaining a containerised version of the app myself: that’s way outside my skill set and the antithesis of what made me choose TNS in the first place )
I’be been running the official Tautulli Docker image as a custom app on TrueNAS for some time. I forget why I switched away from the official TrueNAS version, but this has been working great for me.
The app system is Kubernetes-based, but custom apps are based around Docker images. If you go to Discover Apps then Custom App, you’ll see the section there that asks for the Docker image.
Sure, here is what my config looks like, actually more barebones that I remembered. I think they must have changed what values you need since I set mine up, but mine is still working.
Image Repository: tautulli/tautulli
Image Tag: latest
Image Pull Policy: Only pull image if not present on host
Container Port: 8181
Node Port: 18181
Protocol: TCP Protocol
Volumes - Mount Path: /config
Volumes - Dataset Name: config
Enable WebUI Portal: Checked
Portal Name: Web Portal
Protocol for Portal: HTTP Protocol
Use Node IP for Portal IP/Domain: Checked
Port: 18181
It gets stuck deploying, high CPU and loads of pods. Kubernetes is giving errors about no healthy GPU devices being present. This is correct; there are no GPUs in this system. The settings are to allocate 0 GPUs for each type, though, so I don’t understand why it’s doing this.
Odd, I can’t think of a reason it would even try to do anything with GPUs. Can you share any messages from the logs, if you even get some? Seems like something must be misconfigured somehow.
Just the following over and over again in “Related Kubernetes Events”:
**2024-06-03 15:24:53** Successfully assigned ix-tautulli-custom/tautulli-custom-ix-chart-5ff7bd787c-f2jmp to ix-truenas
**2024-06-03 15:24:53** Allocate failed due to no healthy devices present; cannot allocate unhealthy devices amd.com/gpu, which is unexpected
**2024-06-03 15:24:53** Successfully assigned ix-tautulli-custom/tautulli-custom-ix-chart-5ff7bd787c-zqz4t to ix-truenas
**2024-06-03 15:24:53** Allocate failed due to no healthy devices present; cannot allocate unhealthy devices amd.com/gpu, which is unexpected
**2024-06-03 15:24:52** Successfully assigned ix-tautulli-custom/tautulli-custom-ix-chart-5ff7bd787c-jnwgd to ix-truenas
**2024-06-03 15:24:52** Allocate failed due to no healthy devices present; cannot allocate unhealthy devices amd.com/gpu, which is unexpected
**2024-06-03 15:24:52** Successfully assigned ix-tautulli-custom/tautulli-custom-ix-chart-5ff7bd787c-784pc to ix-truenas
**2024-06-03 15:24:52** Allocate failed due to no healthy devices present; cannot allocate unhealthy devices amd.com/gpu, which is unexpected
**2024-06-03 15:24:52** Successfully assigned ix-tautulli-custom/tautulli-custom-ix-chart-5ff7bd787c-bm8dz to ix-truenas
As I say: there is no GPU in the system and I haven’t selected one to be allocated in the custom app config.
The custom app config is identical to yours with the exception of the host path storage name (tautulli-custom in this case). This is a dataset on the same volume as my other app storage, with a “Share Type” of Apps, giving access to the Apps user and group.
FWIW, nothing is getting written into that dataset.
/var/log/k3s_daemon.log has lots of the following in it:
Am I correct in thinking that if I don’t assign an external interface in the Networking section of the custom app configuration it will use bridge networking by default, and use the same bridge as the other catalog apps?
I’ve just tried creating more custom apps with a couple of other containers/apps and am seeing exactly the same behaviour (looping around spawning lots of pods then deleting them).
I think there’s something fundamentally wring with my Kubernetes set up, (although the truenas and truecharts catalog apps I have installed work fine.
The previous official image was sub-par, as it could not be fully-run as non-root.
Slight clearification:
Onedr0p is not a random creator, he is former (co-)maintainer of the previously biggest helm-chart catalog (k8s-at-home) and (co-)host of the biggest homelab community out there.
We’ve 100% trust in his credibility as a container creator and his skills.
)
here is what I get: