You mean you would be better off if people stopped asking you questions about it?
This is such a user-hostile paragraph. iX is the company that announced in a forum post just a few weeks ago that the apps backend of scale is completely changing, that there will be no (meaningful) migration path for users of third-party catalogs (which up to now were supported).
Can’t you hear the feedback that there is a significant group who don’t want the ship to have sailed at all? What about them?
That employee of the company just called criticism of decisions “slander”. An official account from a technical company that cannot accept that controversial decisions will be controversial and instead complains about disagreement is sufficient to expand my understanding of this decision.
Join the club. I’ll be marooned on an abandoned OS.
I totally agree.
We are very happy to answer questions about how to migrate.
However, if 100,000 users want one thing and 5,000 users want the opposite, we have to make a decision. Not everyone will be happy with that decision, but the decision is made. We have a modest engineering team, and we have to efficiently use their talents.
We are open to users describing their own specific needs and making suggestions or asking questions about how to best migrate for their use-case. For all customers and most users it will be easy, for a small % of other users it will be more difficult or impossible. It will depend on the specific user’s requirements. If you have a business need, please contact us directly.
As indicated many times, Dragonfish will operate just fine through to 2026. We’d recommend users don’t rush their migration plans until they have seen the alternatives and how they can/will develop. BETA is in August and we’ve provided a lot of notice for the transition.
Kris has been saying for at least two years that they’re “all but deprecated” and “a path to sadness.” You announced their sunsetting over a year ago. No, you haven’t yet pulled the plug on them, but they haven’t been viable for a very long time. You have, in fact, discarded this system, and this is the second such system you’ve discarded.
That isn’t my intent, and I don’t believe I have; I believe my factual statements have been substantially correct throughout this and related topics–I’ll be happy to correct any factual errors you identify. But:
No, it really isn’t. It is an issue, but it’s mainly TC’s issue (though one you created for them) and it’s an issue they appear to be on top of. Once they announce how their migration’s going to work, I’ll be able to make a better decision of what I’m going to do, but it’s extremely unlikely that decision will be “use iX’ apps.” My issue is much more that you’re trying to simultaneously act as though this is the greatest thing since sliced bread and also no big deal. Like this:
You know that isn’t true. To give just one example, there will be only one app catalog, under your exclusive control. “PRs welcome,” you say, and that may be, but it doesn’t change the fact that you’ve removed the possibility of third-party app catalogs. This is a big deal, and you continue to act as though it isn’t a big deal.
Moreover, based on everything you and Kris have said, it seems very unlikely that Apps 2.0 will give, or even be able to give, the kind of flexibility with the apps that Helm does without ignoring the catalog altogether and just banging away on compose files directly.
and doesn’t even count FN10, which is arguably a fourth ↩︎
Agreed, definitely not slander. Anything written here could at most be considered libel, not slander - because slander is spoken… 
That depends on the user in question. iX personel likely know more about their upcoming implementation than you, me or anyone else here does. It’s totally feasible that the typical Apps user might not see any difference.
I was disappointed when I realised the option was being removed. Then I concluded that the only non iX-catalogue I knew of was TrueCharts, a catalogue I specifically chose not to engage due to personal incompatibilities. At this point I am not convinced the loss of third-party catalogue functionality will matter in an substantial way, so for now I am going to reserve my judgement until I have a better understanding of how it will be set up.
An argument posted earlier was that TC offered integration of various apps, like ingress, certificate management, VPN and similar, into many (all?) apps in their catalogue. That was indeed a nice perk. A counter is that TC-installs kept blowing up spectacularly over the years due to, as I see it, the TC-team communicating breaking changes poorly, late or not at all. That kind of unreliability made it a no-go for me.
My suggestion here is to wait and see instead of speculating that it’s not going to be good enough. I recall them stating that more details would be released a month (?) from now.
As has been stated earlier, when it comes to the decision to swap out the apps subsystem, that ship has sailed; anyone wanting a chance to reverse that choice would need a time machine set to maybe -6-9 months. Kubernetes is being removed from TrueNAS SCALE in favour of Docker, so spending more time debating that is unlikely to be helpful. Anyone who needs Kubernetes in TrueNAS can run it in a jail or VM and honestly be well off.
If I were to try my hand at constructive opines, specifying what kind of functionality that is important to me or that I would like; it would be to request a smart UI to handle reverse proxy duties, including certificate management through Let’s Encrypt with wide dns-01 support. While I have rolled my own setup with the custom apps of today, it being integrated well would be QoL. I also see value in some form of streamlined VPN connectivity with (user) selected apps.
It’s not liable or slander. Saying stuff like that on a public forum is “shining a big spotlight on your insecurities”.
Definitely not that. But yes, Neo is right, strictly it would be libel rather than slander–but it’s neither, because the statements of facts I’ve made have been accurate AFAIK (and thus far nobody’s shown or suggested otherwise) and therefore not defamatory, and statements of opinion can’t be defamatory[1].
blah blah nuance nuance. IAAL,BIANYL ↩︎
Not even that. The other party has to prove they’ve been harmed by the statement and by his own admission the company’s “profits have doubled”. The only thing the statement did was show a nerve was struck.
My comment was around this statement as “slandering” the product. Apps from TrueNAS SCALE will continue and include a migration from Dragonfish to Electric Eel. They have not “gone away”. No lawyers have been engaged.
We acknowledge that TC Apps will need to migrate to a Kubernetes instance. We have made sure that is possible in a Linux Sandbox with K3s. TC will have to make that decision. Users will then need to decide their own transition path.
We think moving Apps to the new Docker framework will be straightforward for many, but proof of that will be later this year.
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.
There will be plenty of time for transitions and constructive discussions.
Right, just as Plugins 1.0 “continued” with Plugins 2.0. Yes, you’re promising a smooth migration path (for your own apps). If it works as smoothly as you’re promising, that will be a large point in your favor, certainly compared to the previous two transitions. But it doesn’t change the fact that you’re discarding an apps ecosystem based on k3s in favor of an apps ecosystem based on Compose. This, that you appear to be objecting to so strongly, isn’t slander–not because it’s in writing (which would make it libel rather than slander), not because harm to iX hasn’t been shown, but because it’s true. This isn’t just a minor tweak; it’s a massive change, which is why you announced it as such a few weeks back.
You’re continuing to try to have it both ways, and that just isn’t going to work. This can’t be the greatest thing since the invention of the microprocessor, and at the same time no big deal.
What discussions. Still new here but seems the modus operandi is you make the decision—based on flawed numbers—and say: that ship has sailed. …Oh, cant wait to discuss?
Which puts the user right back to where they were in CORE.
Moving to compose is a no-event to me, I’m more comfortable with compose anyway.
It does kill the scale part of SCALE. Is hyperconverged and clustering just out of the roadmap entirely, now?
I feel inclined to quibble. We all use the same container images, but there is definitely a difference how Docker runs containers vs how k3s/k8s run containers - for starters, the Docker runtime is deprecated in k8s and replaced with containerd (default) or CRI-O.
Scaling (the promise of) was based on GlusterFS. And died with it.
Forget the old acronym. I declare SCALE to be the
Storage-Capable Appliance Longing for an Epithet
until someone comes out with a better idea. 
No, because we are not the ones running the show.
Immediately following the announcement, some have already engaged in moving all their apps to compose-in-a-sandbox or k3s-in-a-sandbox. Without waiting for Electric Eel beta to see how the promised autoporting would work. And without waiting till the end of the month to see what TrueCharts would offer as migration path. With such knee-jerk reactions for users, it is hard to blame iX for not speaking until they have something they are confident of—which means something that is already well under development, which means that the decision has aleady been made.
In retrospect, the bad decision was about scaling, and k3s to go with scaling. Enterprise customers are not interested in running apps on their storage, and k3s is too complex for the home user who just wants to run Plex. That left the original “scaling SCALE” (which could not yet scale at that time) rather as a solution in search of a problem…
Going for compose is more convenient for home users; enterprise customers (those who run the show) do not care, as they will keep on ignoring the feature. Like @dan, I suspect that the official catalogue will suffer yet another slow die due to lack of resources from iX, and lack of interest from the community to contribute. But it won’t matter if the provided foundation can just take compose templates from just about anywhere and throw them into SCALE.
@etorix I’m one of those ppl who did not wait for any announcements and went ahead and replicated my truecharts setup with compose in a docker jail. I knew absolutely nothing about docker and compose and got everything working with a steep learning curve in like 2 weeks with trial and error. Now my app setup is 99% how it was with truecharts (only app missing is nextcloud, which is kind of a pita), including traefik, ssl cert on all my exposed apps, Authentik for 2FA, homepage for dashboard and code-server to edit homepage widgets and services on the fly. My Nas now uses 8-10% less cpu and 10-12GB of ram less. CPU temps dropped by like 10°C from 47 to 37 when idling.
As long as iX provides a similar docker experience like jails do now and i can mange everything with portainer, i don’t really care about an included apps catalogue.
@LarsR Excellent job then! And with your apps in a sandbox you’re now largely independent from what iX does—or could do in the future—, and need not come back to the next official environment.
That’s the reward for not running k3s. The issue with high overhead at idle might have been eventually fixed upstream, but that’s hardly an incentive to go for k3s with a low-power home server.
And I’m another one, also learning a heck of a lot about docker and docker compose along the way. And I have to say, in my experience it’s been a heck of a lot more transparent and understandable, and a heck of a lot less bugged than the implementation of k3s (at least initially a year ago - it has become more stable over time).
I also got burned by one of the TrueCharts upgrade issues, and had to reinstall everything from scratch - that wasn’t a pleasant experience. And a plague on both their houses, because the official iX apps seemed so locked down in terms of exposing options it turned out I needed.
So - I get the decision (not that it will now affect me and others, as etorix notes).
Also wanted to chip in that I feel this decision might be a bit too disruptive.
I’ve migrated a more complex setup with esxi/separate ubuntu zfs based nas to a consolidated setup with truenas scale. That setup also ran some k8s clusters setup with rancher. By moving to scale we were able to have less hardware, more userfriendly integration with snapshots.
We now have multiple vclusters running separated workloads on k3s, rancher as management, but for some older vm’s that we’ve migrated we’re just running dind containers with the original docker-compose files …
This is all working fine because k3s offers this flexibility. By taking a step back to just offering docker it feels like we would have to bring the k3s parts ourselves again, and probably layer things out again … but I’m worried that the storage integration will mismatch with what currently maps great (k8s PV’s to zfs volumes)…
An alternative approach with a lightweight approach to automating the docker-compose files on dind would have probably helped out a lot of “starting” users, while still offering a great appliance to more advanced setups.
Enterprise wise we’re now tied into a dead end solution if k3s gets removed and we will probably not pursue migrating things to the new way how things work on scale but rather look at other options like harvester or revisit proxmox because they might be more committed to their choices.
