Removal of K3s based apps from TrueNAS

[Icemanz]

@dan

Obviously. Take a look at what TrueCharts does with their apps and come back to this thread when you understand what I’m talking about.

Ok, that was my attempt at being polite. What I meant was - these things are irrelevant. Explain why you need a third party catalog to handle them for you.

[dan]

@Icemanz

Ok, that was my attempt at being polite.

It sounded very much more like simply not understanding what Ingress (no, it isn’t simply exposing ports), VPN, codeserver, and homepage integration (a critical word you seem to be completely overlooking) are. So for the sake of clarity:

• Ingress: put the app in question behind a TLS-terminating name-based reverse proxy, handle certificate issuance and maintenance
• VPN: route the app’s communications through a VPN server
• Codeserver: Install (and optionally expose via the same TLS-terminating reverse proxy) codeserver in the app in question to facilitate editing that app’s configuration
• Homepage: Place the app in question on your Homepage instance.

All of these, as well as many others, are exposed as options on each of the TrueCharts apps. It’s not simply “there’s an app for that;” each of these, among others, is integrated with each of their apps.

@Icemanz

Explain why you need a third party catalog to handle them for you.

Because iX hasn’t bothered to do it with their own apps. And it doesn’t sound like it’s going to be possible to do, in a comparable way, with Apps 2.0.

Do I “need” it through the apps catalog? No, I don’t need it. I’ve set up and managed my own reverse proxies. I can always add apps to my preferred dashboard manually. I’m sure that with enough digging around on the Internet, I can find how to modify the docker-compose file for qbittorrent to route its traffic through a VPN. I don’t need TrueNAS, TrueCharts, or the apps ecosystem, to do any of these things.

But if you can’t see how it can be useful to have all these features–among others–available in a “check-the-box” or “fill-in-the-blank” fashion across a catalog of hundreds of apps, I have to suggest you just aren’t trying very hard.

[Captain_Morgan]

@dan

Because iX hasn’t bothered to do it with their own apps. And it doesn’t sound like it’s going to be possible to do, in a comparable way, with Apps 2.0.

With Docker Compose and “internal networks” … similar behavior is possible with less customized Apps. It won’t be identical and will require community validation of Traefik, NGinX, Caddy etc.

I’d suggest delaying criticisms until RC.1 - to avoid getting bad information out there.

[Captain_Morgan]

@dan

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.

We do see a much higher percentage of issues from these setups. They are more complex than normal. There is less testing of complete systems. TC and iX have differences of opinion on how things should be done (sometimes for valid reasons - they wanted to support generic K8S as well as TrueNAS. Without an agreement on how to fix, we were collectively delivering a poor user experience with more issues. That’s not acceptable to us or the vast majority of the community.

[Captain_Morgan]

@pmh

I predict that this entire project of moving to Linux for no technical reason, then dropping all features that would have justified that decision, will be the end of TrueNAS and iX. Let’s talk in five years from now.

So, let me set the record straight:

SCALE user count is now very similar to CORE 13.0 and will exceed in Q3.
We’ve almost doubled the total TrueNAS user count since the launch of SCALE
Revenues for TrueNAS have also doubled.
The vast majority of Apps are deployed via SCALE
Jails are still predominantly used on CORE 13.0, but Sandboxes in Linux are becoming popular.
We’ve released two new platforms that need SCALE… F-Series and H-Series.
Both perform much better and have much faster failover.
CORE 13.3 BETA has less that 10% of the interest of SCALE 24.04 BETA.

Bottom line, don’t worry about iX. Focus on your own problems and we’ll see if there is a solution we can provide.

[John]

@Captain_Morgan

Bottom line, don’t worry about iX. Focus on your own problems and we’ll see if there is a solution we can provide.

I think you spelled that wrong. I believe it’s spelled: *FreeBSD 14 solution

[dan]

@Captain_Morgan

CORE 13.3 BETA has less that 10% of the interest of SCALE 24.04 BETA.

When you’ve all but said, “CORE is going away; SCALE is the place to be,” this shouldn’t be a surprise–I think the term is “self-fulfilling prophecy.”

@Captain_Morgan

The vast majority of Apps are deployed via SCALE

Since Apps don’t exist on CORE, this stands to reason. And if you’re intending to compare to plugins on CORE, you agreed 18+ months ago that they weren’t to be recommended, and it’s been over a year ago that you put out a blog post saying, “Plugins are dead, long live Apps.” Once again, self-fulfilling prophecy.

One of the headline features of SCALE is dead. Another, you’re drastically scaling back^[1]. The technical reasons to favor it over CORE seem to be dwindling.

---

1. and since you’ve already discarded three apps/plugins ecosystems as “too hard to maintain,” I don’t see any reason to believe this one will last any longer. Sure, it’s easier to maintain–I don’t actually know this, but I’ll accept it for the sake of discussion. But Apps 1.0 was supposed to be much easier to maintain than Plugins 2.0. And Plugins 2.0, more so than Plugins 1.0. Each in due course has gone away. ↩︎

[John]

@dan

I think the term is “self-fulfilling prophecy.”

Weird because I call that “common sense”.

“Why isn’t anyone trying the new BETA of the product we are depreciating?! …Oh, so frustrating!”

[dan]

At least we’re in more agreement here than on “bleeding edge.”

[John]

“cutting edge” / “bleeding edge” / “newer” is a sore topic. I will do my best not to bring that up again…EVER.

Hey! We do agree. Let’s be friends. In fact, can I help tear down the next poor bastard’s feelings that uses the phrase?!

[John]

Wait! Hold on a second!!
These numbers you’re referring to, @Captain_Morgan are not the same ones you use for actual “business-decision-level decisions” (“projections”, “funding”, “allocations” and whatnot) are they? I mean, you do see the usage/download numbers became biased as soon as you made the announcement(s) and cannot be actually used accurately for things like “projections” and “allocations”, correct?

[John]

Actually, no! Not my place. I took the “numbers comment” in humorous tone at first but now my thought of them being “actually thought of as accurate” makes me see it as another mark in the “my ‘small donation’ to a BSD company that pivoted years later and tried to push me something else” column. I’m not sure I want to actually know if you guys think those numbers are biased or not, but I guess it’s worth mentioning because other people may not default those types of comments to a humorous spirit at first so you may want to assuage doubt at some point.

[Captain_Morgan]

@dan

and since you’ve already discarded three apps/plugins ecosystems as “too hard to maintain,” I don’t see any reason to believe this one will last any longer. Sure, it’s easier to maintain–I don’t actually know this, but I’ll accept it for the sake of discussion. But Apps 1.0 was supposed to be much easier to maintain than Plugins 2.0. And Plugins 2.0, more so than Plugins 1.0. Each in due course has gone away.

Plugins (Apps) in CORE are available but retiring. Jails are still maintained (we all agree jails are a great technology).

Apps 1.0 provided in Angelfish have survived through to Dragonfish. They are way more popular than Plugins ever were. We think that was the right decision.

Official Apps 1.1 in Electric eel will port directly from Apps 1.0 through to Electric Eel and well beyond. There is no change from a user perspective.

Your specific issue is:
TC Apps don’t port as easily. They were designed for generic Kubernetes.
The TC Apps can use K3S in a Sandbox with access to the same data. They will need an alternate migration path and UI. TC has to make that decision.

Please stick to the real issue rather than slandering TrueNAS to make a point.

We’d all be better off if we focused on how to transition rather than arguing about whether transition should happen. That ship has sailed.

Next month, testing will start. Community Apps can be built (but its probably reasonable to wait for the basic Apps to be solid).

[truecharts]

TC Apps don’t port as easily

We use mostly the same Helm backend as you do.
The reason is that for BOTH of our catalogs the port isn’t easy at all.

That is, however, not the only reason we will stop building SCALE Apps completely:

• It will take hunderds of hours to port all our Apps, we dont have the luxary of having a paid full-time staffmember to do such a thing. So we simply cannot
• We always where a Helm-Centered project, our goal was to build awesome Helm Charts as well as SCALE Apps from them. We’ve no interest in starting a completely new project
• iX Does not even allow third party catalogs in Electric Eel, so we couldn’t even port even if we wanted to.
• After all this, even if we wanted to rewrite everything, we wouldn’t be inclined to “donate” the code to an iX-Managed catalog

So its a combination of:
A. “Its very time consuming/hard”
B. “We’re kinda done with supporting propietry opensource apps systems after this fiasco”

Note: what is meant with “propietry OpenSource” are systems that are limited to a single vendor, regardless to the fact its OpenSource, as that requires per-vendor customisation work.

They were designed for generic Kubernetes.

Everything was normal Helm, underneat the middleware, for both projects. Even sharing most of the same helm templating backend.

We’re also not more-or-less designed for generic kubernetes either. Our code contained significant SCALE specific tweaks and patches as well.

The TC Apps can use K3S in a Sandbox

Our SCALE Apps cannot, though our Helm-Charts, technically, can.
However: we will not use such a solution, not advice it and not provide any level of support for it.

They will need an alternate migration path

As stated in our latest announcements, we’re working on a migration path for our users. This will not involve SCALE sandboxes though.

and UI

Migration and running our Helm charts, technically, does not require a GUI at all. How we are going to deal with that for users that prefer a GUI, is going to be published by us at a later date.

TC has to make that decision.

We’ve quite thoroughly published about that already

than slandering TrueNAS to make a point.

It is a factual statement to state the bad history iX has with Plugin and Apps systems.
Though it should be applauded that iX takes responsibility for it by ensuring, at least, their own Apps are automatically migrated/ported to their new system.

edit
Removed the question to officially confirm removal of third-party catalog support as that was already answered by @kris earlier. Appologies!

[sfatula]

@Stux

Docker compose is more suitable for the target which is simple apps for simple uses.

It’s compose. What I don’t fully get is IX keeps saying docker, they must mean specifically compose. Custom Apps in their current form are very close to the same idea as running via docker. You have to answer the same questions, i.e. where to store my stuff, network, etc. It’s a UI vs command line. People on Reddit and here seem to be so lost on custom apps in many cases. It’s one of the simplest concepts I’ve ever seen so I am not sure people want docker at all. They want docker compose. I guess it will be simpler to just use standard compose files for the average Plex guy and the rest like it. I do think Scale is trying more to fit it with the homelab or part time playing with Plex crowd. I do think it’s a little less appealing to Enterprise though.

[truecharts]

ingress on a docker is ports: 8008:80 - that’s it - simple

On Kubernetes such a connection is done through an “object” called a “loadbalancer” (not to be confused with an actual loadbalancer within networking jargon)

Ingress is for reverse proxying

If you want to run a k3s container you have the official registry or truecharts …

Seems some clarification is needed here:

Helm charts still use containers, the same containers that compose uses.

Helm Charts are to Kubernetes, what Docker-Compose is to Docker.
“just another way of deploying containers”

There is no such thing as “k3s containers” and (mostly) no such thing as “truecharts containers”.

We all use mostly the same containers from Dockerhub, LinuxServer, GCR, Quay etc

[truecharts]

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.

Could be, could not be.
We cannot confirm any of this, or even take it into account within our numbers, as iX has removed the previously (years ago) publicly available statistics.

@Captain_Morgan

If that is incorrect, please share your numbers.

We’ve no interest in a pissing contest, or argument, we just wanted to highlight that thousands of users are affected and that should not be downplayed.

[quietcook]

Is there a reason that k3s was not deprecated? My understanding is that SCALE is an attempt at an enterprise product and I have never seen a respectable enterprise partner pull a feature from their product without deprecation.

[truecharts]

We do see a much higher percentage of issues from these setups

Which just got closed with “using third party catalog”.
(which is completely reasonable)

They are more complex than normal

Sure, the thing with third parties is that they might want to do things a different way, including more complex.

they wanted to support generic K8S as well as TrueNAS

Not really, we could’ve technically load the completely same GUI experience and resulting templates, as iX is doing, with little work.

Its a difference in, well, a design philosophy:

• TrueCharts: Puts all helm-chart options front-and-center
• iX: Abstracts things away more

We even debated in March to make a simplified catalog following more of an iX-Style GUI pattern. But held-off on that due to the signals iX was giving regarding potential removal of helm-charts completely.

Without an agreement on how to fix

There could’ve been an agreement, if iX had reached out about their concerns with UX. This has not happened.

we were collectively delivering a poor user experience with more issues

The thing with Freedom, which is funny to explain to a company that has “datafreedom” as its new slogan, is that people building things for your free-and-open platform, also have the freedom to give a bad experience.

That’s not acceptable to us

The thing with Freedom vs an enlightened dictatorship, is… this…

or the vast majority of the community.

Then… they had the freedom, yet again, not to use the things they deem unstable or giving them a bad user experience.

---

Besides the technical reasoning behind moving to docker-compose, which we can completely follow.

This is also certainly a move from a “free and open platform” (which even CORE Plugins where) to a “Free within my walled garden” platform.

This has also contributed heavily in our decision not to port things towards Electric Eel.

---

We’ll leave it at this, everything is said by now from both sides.

From this point onwards, we will only post the future migration announcement(s) and leave it at that.

[John]

@truecharts

We’ve no interest in a pissing contest, or argument, we just wanted to highlight that thousands of users are affected and that should not be downplayed.

How many CORE users were affected with the “other decision” (wish I had someone defending “me”)?