The problem here is:
We, as a developement group, have certain standards and offer pro-active support on what we build.
Giving advice to new users to do things that inherently voids our support (such as using hostPath instead of PVC).
When you yourself are quite clear about not understanding everything perfectly yet yourself, this means those users will still need our support if things go awry. Which they either, in some cases, won't get due to customisations or puts the burden of supporting your advice on our support staff, which already has a daily job of walking people through permission issues with just the default(!) 568 user/group settings.
Thank you for your prompt response. I back you 100% that as the team that creates these charts, you get to pick what and how they work, and what you will support. I have decades in operations and fully understand your need to limit variables or it wouldn't be possible to provide support. I also agree that giving a response that moves people out of support is not a good idea,
especially without warning them. I will keep that in mind.
That said, what makes good practice for you (to control your support effort) and what makes good practice for a user will not always align 100%. Being willing to move out of official support can yield a superior experience as well as make it much easier to self-support.
I change users also from a visibility perspective. Having an owner set to "radarr" instead of "apps" told me to look at "radarr" instead of "one of the 24 applications" running as apps. I can use tools like netdata to show activity by user context in a predefined historical graph. This showed me that "tdarr-node" consumed tons of CPU while the NAS was struggling elsewhere. Seeing "Apps" was busy wouldn't have communicated the details required.
Visibility is also an advantage of host paths over creating a claim for a persistent volume. A host path is by default visible to the wide array of existing tools in ways that a PV is not. Easy remote access via TrueNAS built-in functionality SMB/NFS shares, SSH. Easy local access via shell using built-in tools like MC, and nano. We can use all the built-in data protection tools (snaps / replication / rsync / cloud backup) We just have a ton of options that each have a ton of easily researched information out there. Access to data in a Kubernetes-managed PV is an extra layer of complication with comparatively fewer tools and far more limited understanding available. Admittedly, with your documentation (quick start guide) this is less of a barrier than it used to be. The app shutdown requirement can be hard to live with.
I am not familiar with the advantages of sticking with PVC. The restricted access is a win from the avoiding unintentional change perspective and it would improve ease of support. Losing access to truetool for backups is significant, especially as it backs up both the app config, PV claims and the associated volume. This all-in-one package, combined with straightforward rollbacks is compelling.
I don't find it silly at all to indicate why I used your feature to achieve my preferred practice. we are not having a private conversation, Folks that read this thread may learn, I know I did. Secondly, it's an effective communication technique.
I appreciate your additional details on what ids/groups you use by default, and why you alter from them. I now see you document your id group use by app in the Apps section.
(btw Netdata is available in stable, but your apps section, stable is missing it, and the Manual app list has as incubator broken list for it)
Lastly, thank you again, for your product, for your support, and for your willingness to dig in with the community, actively engage, and express what you do and why you do it. I definitely appreciate it. I suggested a few missing charts, and one of them was quickly added. Exceptional.
