Judging by the low numbers of TC users
We’ve gone over your metrics and have come-up with significantly higher numbers. We estimate closer to triple to quadrupple your previously posted numbers.
We completely understand that it’s important for your marketing to keep acting like “almost no one uses TC”, but that “almost noone” is actually thousands of users according to our metrics.
One set of charts doesn’t play nicely with another set of charts and the users get a bad experience
Thats a very close minded reason to excuse yourself for locking down the new apps system from third parties completely.
Of course no home user is using kubernetes in any meaningful way. Most enterprises barely use it any way. It’s a container orchestrator designed for scalability, load balancing, self-healing, and automated rollouts and rollbacks - not exactly “I want to run plex” territory. It adds a huge amount of complexity between downloading a docker and running it - case in point - you needed a whole custom store (truecharts) because docker images almost offer a compose, few offer a helm chart.
This as well. Hosting apps on your storage is a home user / very small business concept.
Citation needed.
How big is the TrueCharts team? My impression has been that they’re pretty small, and I expect they all have day jobs–but they’ve been able to come up with a catalog of nearly 800 charts that frankly run circles around yours. That has to at least suggest that they aren’t all that “difficult to maintain, port and integrate.”
But an important question has come up that I don’t recall iX’ having answered: will Apps 2.0 allow for third-party app catalogs? Or is it walled off to only a single, iX-managed repo?
True enough. And how many of those compose files incorporate Ingress? VPN access? Codeserver? Homepage? I could go on, but these are enough to make the point: vanishingly few of the “official” docker-compose files provide any of these integrations; none provide all of them. Will iX’ New and Improved™ Apps provide them? I guess we’ll see, but I’m not betting on it, particularly since none of their Apps 1.0 charts did.
And I’m being pretty hard on iX here because they have a long history of “overpromise and underdeliver.” They love to announce great things, and then get distracted by teh new hawtness and the previous announcements fall by the wayside. Consider Plugins 1.0 (PBI), Plugins 2.0 (iocage), Asigra, Nextcloud, somewhere in there has to be the release formerly known as FreeNAS 10, and now Apps 1.0. Sure, their commitments don’t always fall through, but it still happens a lot. Now they’re promising a bigger, better, more up-to-date app catalog, because Docker is so much easier than k3s. I frankly don’t believe it, and I think I have plenty of objective reason to be skeptical–that is after all what they promised with Apps 1.0 (and the reason they gave), and before that with Plugins 2.0 (and, again, they gave the same reason).
Fair, and we’ve also intentionally not really pushed the envelope on adding new Apps while we were not fully settled on Helm/K3s as the right tool for the job. That became apparent almost on day 1 as the bug tickets and feedback started rolling in 
The new implementation will be a single catalog within the TrueNAS UI, which is fully open and has the same Community/Official/Enterprise train of applications. Pull requests welcome. This will be done for quality and supportability reasons primarily.
However on the flip-side the backend will be much more standard. Meaning we’re vastly simplifying what our middleware touches, and docker/compose will behave like it would on a traditional Linux install. This means it is possible to use 3rd party tools and mechanisms to “drive” docker around. Like Portainer, Dockge or other tools which can help manage your catalog of applications. Any person or group could potentially author their own “Catalog Management UI / Tool” and have it added as an App to our open catalog if they so choose. This means they have flexibility to build an interface as simple or complex as they want for whatever target audience they want to cater towards.
That is a fair point, and I’m not sure if we would try to add that type of integration yet. The reason being based on the numbers and how many people actually use/need ingress in a homelab. Judging from the usage stats, that appears to be a pretty small minority of current SCALE users, far less than <10%.
Haha, I get a chuckle when I see folks bring up PBIs. That was my baby and pretty much a one-man show. I own that one 
At the end of the day there turns out to just not be that much demand for a FreeBSD-based desktop. Even trying to get buy-in for FreeBSD on a desktop/laptop with FreeBSD developers was tough, considering 60-75% FreeBSD developers at your typical BSD conference were running MacBooks. Even they had no time for that nonsense
Wonderful. Don’t waste time talking to me. Go dispense evil!
CAN is the operative word there. I trust you’d only make me fill in simple things. And this is a also a double edge sword because what happens when your schema doesn’t allow for me to customize the port or the protocol? Or what happens when your default values are “unsafe” (do I then plan to modify those “horrible defaults” and thus fork your charts and now we have two)?
I honestly don’t care what all the major open-source projects are doing or using. I am not a dev team; I do C in Vim with a makefile (I need a terminal and LibC). I do C because I want to do whatever dahell I want and I don’t want to have to open this or that or even use “a browser” (that doesn’t make much sense so I will briefly expand and the following may read like gibberish); For the most part, I want my stuff to be headless (no gui) and leave me alone. For example, my latest concept is: why do I need to open a browser to “gitlab” to essentially just list my repos (It’s another thing where I need to authorize users, create recipes, etc). So, I mocked up a deamon and ping it over TCP to give me the list/information instead (essentially, now I don’t need a Gitlab/cgit/or whatever container with accounts, nginx, apache, ACME, etc). I don’t want to have to use a browser to show the “battery level” or “the capacity level”; I want to assume it is okay, until it tells me otherwise.
DevOps is getting overly complex in some ways, and I guess my stance these days is more along the lines of “simplifications and (re)evaluations”. -i.e. I don’t need ‘gitlab’ to manage users and their permissions and reinvent packaging, because there are already mechanisms to do all of that.
I don’t want to have to manage/change/add to/think about anything. “There, now I’ve set you up and told you what to do, do it and leave me alone”. I understand that sort of describes autoscaling stuff but that isn’t exactly what I’m talking about.
The Mend.io thing sounds cool but part of what I’m doing is eliminating dependency (less moving parts thing) so the concept is wasted on me.
I know you have data and all I have is a feeling based on what I’ve seen on both forums, but I remain very skeptical of this number. There have been several guides written (including one by me) on how to set up one reverse proxy or another on TrueNAS, largely for the purpose of addressing one or both of two issues: (1) TLS termination, or (2) providing a simple URL for services that doesn’t include custom port numbers. This has been a long-standing perceived need by many people.
And it’s a need you yourselves recognize, providing a Nginx Proxy Manager app. That’d be pretty low on my list of tools to handle these needs[1], but handle them it does. But just like with all the other guides, scripts, etc., you have to manually set it up for each app. Ingress automates this–for every app, you can check a box, enter a FQDN, pick a certificate (yeah, it’d be nice to pick it from a drop-down rather than typing in a name), and it’s done. If there’s value in having NPM, surely there’s more value in having it automated.
The other question is whether you’ll be able to at all. In a standardized way, that is, across all your apps. At a minimum, people using torrent apps are going to want VPN integration. Even though I don’t use Homepage, I think it’s nice that the TC apps have the ability to hook into it, giving a nice (and customizable) dashboard for your apps. But I’d expect this would need to be designed into your system very early on.
largely because it’s very difficult to troubleshoot when it fails to obtain certs from Let’s Encrypt ↩︎
Of the top of my head, as example. I’m sure the devs can implement this easy.
# zfs create zdata/longhorn-ext4 -V 500G
# mkfs.ext4 /dev/zvol/zdata/longhorn-ext4
# mount -o noatime,discard /dev/zvol/zdata/longhorn-ext4 /var/lib/longhorn
over ext4/xfs over zfs, that is not real support
ref:
The new Apps system is totally open to third parties. Its just using Docker Compose not Helm charts.
Third parties are welcome to run Kubernetes in VMs or Sandboxes and control their own Apps.
There are no good solutions for running Kubernetes and Docker Compose together, so a choice was needed. We decided to focus on user experience and community preferences. We know its doesn’t suit a small % of users, but that is reality.
Both our statement and yours can be true.
TC has less than 5,000 users, which is way less than 5% of the user base. If that is incorrect, please share your numbers.
Those users can stay on Dragonfish as long as they want.
They can migrate to Kubernetes-baremetal, VM or Sandbox.
If you want to argue, please DM me. We are not arguing on your forums.
…but totally under your control. There’s one apps catalog, and you run it; there’s no option for third-party apps catalogs. That’s a significant difference. TC may be exaggerating in saying it’s “locking down the new apps system from third parties completely,” but it also isn’t “just using Docker Compose not Helm charts.” This is a huge change in posture on iX’ part.
Where did you see iX say that they are removing the option of third party catalogues?
Earlier in this very topic:
Apple is in the business of selling Macintoshes (and now iPhones, iPads). As a necessary requirement for this hardware business, Apple develops its own OS.
In addition to MacOS, Apple has also released a number of applications. Some of these were great enough to give rise to an ecosystem and/or let users base their own business or workflow on them. Hypercard, Claris, FileMaker Pro… Invariably, this ended up badly when Apple ultimately dropped the great app because it was not an essential part of its own business (hardware+OS).
#end digression
iXsystems is in the business of selling ZFS-based storage servers. As a necessary requirement to this hardware business, iXsystems develops its own OS—and allows a version of it to be used freely on generic hardware, thanks!
As an aside, iXsystems has repeatedly tried to grow an app ecosystem on top of the ZFS storage. @dan has listed the various incarnations of these attempts, from PBI to the upcoming docker-compose in Electric Eel. We know how these ended up… Running apps is not an essential part of operating ZFS storage; users who invest too much the app enviroment that is provided at the moment as an extra to their storage plateform can (possibly “should”) expect to get burned.
*whispers* Psst! Good thing you didn’t say: “bleeding edge” cause they get “Pissed-off”!?
Yeah, it’s not like that phrase means anything.
I appreciate the switch to docker. From my point of view, k3s was too komplex and resource hungry to just run a few apps on a storage server. And I was missing a proper, easy to use backup concept, too.
Now we have VMs, jails, and soon docker. For me, that seems like enough choice to support most use cases.
Oh, next you’ll tell me there is no such thing as “the bus factor” either.