Thanks for this feedback. At risk of quoting myself, you’re the poster child for someone who is too invested in an app environment which is NOT the primary feature of TrueNAS, and thus not guaranteed to be stable enough.
Your options involve setting up k3s (or k8s) in a sandbox, and then be satisfied that you’re independent enough from iX further choices, or, indeed, look elsewehre.
FWIW, it doesn’t seem the TC folks are satisfied that this would be “independent enough from iX’ further choices”–I’m inferring this from their public statements that they won’t be using this method, and won’t support those who do. I don’t think I blame them.
@dan I know. But I do not have the technical skills and knowledge to assess whether this is technical (some limitations of sandboxes), politico-technical (avoid systemd), purely political (get totally out of TrueNAS[1]), or a mix of various reasons.
Other developpers/users affected by the removal of the official k3s environment have “to do their own research” I guess.
a choice which I can undestand ↩︎
Count me as another person who lifted and shifted all their apps over to compose as well. The TC people have been really dishonest about a lot of different things over time, and the apps themselves break randomly. I spun up docker on a Lenovo Tiny from like 2015 and the apps are way, way faster than on my main machine running TC apps, which is a gigantic eypc machine. I was gonna remove TrueNAS entirely from my setup until this announcement, and now I’m working it back into my setup. I stand 110% with iX’s move here.
Well, at the time that we were making this choice we were looking at a couple of options. And it was in the early days of scale when clustering with k3s was announced with which we have had experience.
So it seemed as if the “k3s feature” was going to be pretty fundamental going forward in the truenas scale ecosystem. It also aligned with most of the industry going to k8s as a standardized API for deployments, both for cloud deployments as edge/local …
We had indeed not foreseen that it would be abandoned so quickly, but perhaps then truenas is a posterchild of not clearly marking as wat is experimental (which I believe enterprises should be able to do to recon the market’s to get feedback) and instead just listing it as a full on feature without commit’ing to it.
I would like to refer to: https://www.truenas.com/docs/files/SCALE22.02Docs.pdf and quote:
Unlike other HCI platforms, a user can get started with TrueNAS SCALE on a single node and incrementally scale up and scale
out to over 100 storage nodes with many additional compute-only nodes. TrueNAS SCALE is true Disaggregated HCI, meaning
storage and compute can be scaled independently. Each node can support Virtual Machines (with the KVM hypervisor) as well
as Docker containers by using native Kubernetes.
Does this read to you as something that is an afterthought or is something experimental?
Nor I. And like you, I think the option you give as “purely political” is entirely understandable, and I’d say probably reasonable.
That’s a pretty strong statement. Though were I so inclined, I think I’d be justified in making that claim of iX (the future of CORE, anyone?).
That hasn’t been my experience, but to each his own.
I’m speaking fundamentally here. One of the few times I’ve ever had to ask them for help, they accused me of missing a step and closing their ticket, without ever letting me explain that no, I did not skip whatever step. Additionally, there’s a lot of FUD in their Discord RIGHT NOW saying that third party catalogs are not allowed, when multiple people from iX have stated that simply isn’t the case. I could go on, but this isn’t the “Litigate TC” thread.
No, multiple people from iX have stated, in this very topic, that this literally is the case. There will be one app catalog, and iX will manage it. The product will not allow any third-party app catalogs. Morgan’s trying to soften this more recently doesn’t change this fundamental fact.
I can still bring my own compose files, and use images from ghcr/dockerhub/wherever so I don’t need to use a catalog or whatever.
I reckon people will always be able to spin up their own jails and do whatever they want in them - including installing stuff from other repositories, etc.
What is suspect iXSystems is trying to move towards is a smaller cohort of known-good apps/projects/whatever that they can manage more easily and include in quality control.
Anytime there are a ton of apps, invariably there can be QC issues that cost a lot of engineering resources - precisely for the customer segment least likely to fork over $$$ to iXsystems.
iXsystems likely recognizes the benefit of plex, traefik, and other popular packages for SCALE but doesn’t want to invest any more than the bare minimum since these packages are basically a form of advertising (ie a cost center), not a source of $$$ for iXsystems.
Good for you. Doesn’t change the fact that the only public example you gave of TC’s supposed dishonesty was, well, wrong, because what you called FUD was in fact the truth.
So it’s fine for you to make public (and spurious[1]) accusations of dishonesty–but when I demonstrate your dishonesty[2] in doing so, I’m being “creepy” and “psycho.” The poster protests too much, methinks.
you say “this isn’t the thread for it,” but you’re the one who brought it up ↩︎
Why am I calling you dishonest when I just made a point of how strong an accusation that is? Because the proof that what you call FUD is actually the truth is right here, in this very topic. You can’t not know–or at least, have no excuse for not knowing–that this statement of yours is false. ↩︎
IX did say:
“If there is a need for 3rd party catalogs, there will be multiple solutions, even if they are not the same as the previous approach. Docker Hub is a catalog in its own right. Dockge and Portainer also have catalog-like functions. We are open to feedback on this and how to make solutions easy to use.”
So, it is true that as of today, long before Eel is released, there are no third party catalogs, nor are any planned that we are aware of. I do agree with IX that docker hub is a catalog, but not a catalog within Scale and not quite as simple as an in Scale “app” could be as often you need to craft your own compose files and sometimes you have to even find the github or other source of the code for examples and various env vars, etc. They did say they are open to feedback on this. The issue there of course is the existing catalog, Truecharts, will certainly not be one of them. I personally do not use them so no effect on me but I know a lot do. In a sense, user contributed “apps” could be considered third party, but typically those are one offs and don’t have a system integrated around the apps.
If we assume k3s is gone and it is, then, what would a third party catalog really entail, and, who would create such a catalog? Is there even a way to make docker hub easier? I’m not sure it matters that there is likely going to be no third party catalog at this point. I don’t think that’s the issue. The issue is more the loss of the existing third party catalog and the systems built around that.
Would a new topic be appropriate as they asked for feedback and said they were open, to discuss ideas on how one could make things easier for all given the docker compose changes?
I’ll make a daring, revolutionary, proposal: What about WAITING for the new compose environment to land in beta, and see first hand how much tailorisation[1] is required to have a random docker image working in Electric Eel?
So far, it seems that early migrations to docker-in-a-sandbox went well, that the #1 issue is about attaching apps to a reverse proxy service, and that there is no #2 issue.
Maybe all that is needed is a new video by @Stux?
Hope being that “my tailor is swift”… ↩︎
Nothing like those words have been said. Its probably time to wrap up this thread. We can restart when there’s software to test and feedback on how to improve.
