Excellent!!!
Not quite so excellent. Since EE Beta is out, it would help if the community could start to recreate all the apps that were in the TrueCharts catalogue and probably some that weren’t, and also if possible to create automated migrations from these TrueCharts apps to EE, so that when a production version of EE launches, a head start has already been made on these.
I would imagine a lot of the community apps were done by people who were using them from truecharts. Docker-compose will make it much easier to roll things out when EE is launched.
Automated truecharts migration is probably not going to happen. Good guides on how to pull out config/appdata would be the best case.
If you fancy writing one of these for Uncle Fester’s Basic TrueNAS Configuration Guide that would be brilliant. 
For the most part, I’m just using the arrr/plex media server apps. Once I figured out my app config/data were on a single drive and vulnerable, I started adding extra mounts for the backup folder locations for things like sonarr/radarr. Was a quick restore for me when moving to community. For plex, I just added an extra mount and brute force copied the relevant folder to my raid-z2 drives, then push that back in. So elegant isn’t how I work. I’m also mostly terrible for documenting without a partner. At work, I pair up with someone because I take too many shortcuts (learned from many years of experience) then have a 3rd person who knows nothing about the project to see if the docs lead to successful recreation 
You can’t pick and choose, iX has to either manage/oversee everything or allow other Catalogues to do it on their own. iX removed k3s / kubernetes, so people who used apps with alternative forms which had more features/integrations than the “basic” apps are now screwed.
Honestly this way is better, can’t be Marie Antoinette here (“Let them eat cake”), no 3rd party stuff, run your own compose files or run the official/community apps maintained by iX, no middle man, one person/company to blame.
Alternative catalogues are always at the mercy of whatever plaform people run their apps on, aka TrueCharts runs on Helm, and SCALE ran k3s/Hem Charts, same thing with Linuxserver or etc
I decided to use truenas as NAS, and move all my apps (90% truecharts) to another machine running ubuntu server + microk8s. This way each system will do what it was built for.
That’s pretty much what I’m thinking, though I’m first going to try TC’s migration process to the Talos VM (which will be running under Proxmox, not under TrueNAS).
I was pretty darned critical of iXsystems for doing a sudden death cut-over from Kubernetes/Helm to Docker (rather than having one or two releases where they could run in parallel - though of course there might have been significant technical challenges or even impossibilities of achieving this) - because having encouraged TrueCharts to produce their own catalogue, they then cut both the TrueCharts developers and all their users off at the knees.
Certainly migrating your apps off TrueNas altogether is a very valid approach - running a Talos VM either under TrueNAS or on a separate (Proxmox?) box might be a better apps platform than the TrueNAS Docker one for some people. But for my limited set of apps, I want both: a) to keep my infrastructure as simple as possible, and b) limit the amount of effort I spend moving apps from one environment to another, so I will go with TrueNAS and Docker myself.
That makes sense, I’ll likely do something where I keep some apps on my NAS but will have a main apps platform on another machine I manage. The move to Docker with open docker-composes allows more portability, so it’s nice, because some people will be burnt with the remove of Kubernetes/k3s, aka what happens if they go all into LXC or jails in the future, so they may not trust iX enough to “have all their eggs in one basket”
At this point, I sure don’t. Even the sandboxes created with Jailmaker look like they’re going to be replaced with LXCs in future releases, so I don’t think trusting iX to maintain any kind of stable apps platform is a good idea. I doubt Compose itself is going away (though I would have said the same thing in April of k3s), but I don’t have any confidence at all that they’ll still have an actively-maintained apps catalog in a couple of years. But time will tell, I guess.
No sign of nspawn being stripped out though (Yet?). And LXC can (in theory) run Jailmaker sandboxes, perhaps with the help of an import script.
Jailmaker uses LXC images to make its jails, in many ways the script is actually a way to run LXC images with systemd-nspawn
…and that is the key word. There was no sign of k3s, and everything that depended on it, being thrown out the window either. Until they announced it.
History is littered with technologies that abused the trust of their user base and which became obsolete not just quickly, but sometimes overnight.
Enterprise data-centres will typically stand-up separate infrastructure for VMs and containers and NAS, and so would never have used TN functionality here.However it is possible that Enterprise users might have used Kubernetes apps in branch offices where they want to limit the number of servers, but if they did I would imagine that they won’t trust iX with that again.
For small and free users, I think that iX’s trust bank account is pretty much empty now. If they deprecate one more apps technology that users have invested time and effort into (unless they can justify it as being forced on them by an external change) I think these types of users will have had enough.
Of course there’s going to be a spectrum there–some are already there; others might not get there for a while yet. I think it’s pretty obvious I’m pretty much there.[1] But an awful lot of people seem deliriously happy to have Docker in there (to the point that it seems we have lots of people running beta versions in production), so that might delay the “had enough” point for them.
I have one iX app running right now, and that’s Tailscale. I’ll try TrueCharts’ Talos migration. If that doesn’t work as desired, I’ll work out another way to run the apps I want on my Proxmox host. I don’t expect to do anything significant with iX apps for quite some time, if ever. If they actually put in the effort to provide the features TrueCharts did, that might change my mind, but I’d still be wondering when they’re going to pull away the football again.
Not such that I’m done with TrueNAS (options for an open-source ZFS NAS really are limited), but that I’ve lost trust in it as an apps platform. ↩︎
The simple reason users are happy with docker, it’s so much more approachable than helm/kube. I won’t feel trapped by ix/community/truecharts decisions, I can just do it myself. If I need to go to another OS, that won’t be difficult.
And have fun with truecharts, they’ve only done 2 breaking changes and had a spectacular meltdown in the last 18 months. I think there’s a saying for that: when someone tells you who they are, believe them.
As for ix/comm apps, and truecharts for that matter, they are just pulling images from someone’s project page. Just roll your own apps based on those images and not have to worry about iX or TC changing directions. Bonus will be if they do, you can move your docker-compose to a different system easily. Something you just can’t easily do with Helm/Kube, which is the whole issue in this thread.
Not to mention, Truecharts/iX could have made it easier to migrate by suggesting end users separating app config/data at install. After the 2023 refactor, really don’t understand why TC didn’t at that point. Then again, you don’t have a captive user base if they have options 
And I really did think about moving to bare metal debian with openZFS when TC broke all their apps. I didn’t want to put all the time into learning helm/kube and knew I could do everything I need through Docker. The Scale UI is nice, but there are plenty of other management projects out there.
Only if you’re installing your own images for which pre-built apps aren’t available–and in that case, Dragonfish and earlier releases already had tools to deal with that situation. If you’re using “point-and-click” apps, the backend technology is irrelevant.
People like to mention this as some kind of “gotcha,” but leave out a lot of relevant points. First, the most recent breaking change was a direct result of iX breaking things for them–they’d been using a k3s feature that iX removed in Dragonfish. TC provided, documented, and automated, in advance of the release, a migration path for this one, and the existing apps continued to work, including upgrades, until you got around to running the migration. Second, even with the first change (which was not handled by TC nearly as well), no data was necessarily lost. Backing up, removing, reinstalling, and restoring was a pain to be sure (and it all had to be done manually), but it was possible, and fairly straightforward, to keep your apps and their data. Third, it isn’t like iX hasn’t completely broken apps on more than one occasion.
Sure, but now you’re outside the realm of “apps.” You’ve been able to do this in every release of SCALE and the last several releases of CORE. But iX believes (and so do I) that people want plugins/apps[1], such that they’ve been providing this feature for 15 years. It’s never worked all that well until SCALE, and even there the apps they provide have been pretty lacking in features, but clearly iX thinks enough people want this for it to be worth their time making it seem like they have it.[2]
Now, maybe I and they are wrong, and people just don’t care about being able to install a bunch of apps by point-and-click. Maybe all people want is “paste in your compose file.” But I don’t think this is the case.
…along with all the app data, which isn’t as easy. I doubt it’s inherently any more difficult with Helm/Kube, except that SCALE keeps those charts out of sight and thus harder to move readily.
In what way do either iX or TrueCharts not do this?
How does it benefit TC to have a “captive user base”? Leaving aside whether they do–and judging from other topics here, it doesn’t look like they do–why do they want a captive user base on a platform they (very vocally) no longer support? It’s not like they’re making any money from those users, other than whatever donations they might be making.
For purposes of this discussion, I’m defining plugins or apps (which I’m using interchangeably) as software that you can install by point-and-click, perhaps filling in pre-defined fields on a form (i.e., filling in “Plex claim token” would fit here; needing to figure out and fill in “additional environment variables” wouldn’t). “Paste in a compose file” does not fit this definition. ↩︎
…but, disappointingly, never worth enough of their time to actually make them work well, keep them up to date, etc. I doubt changing to Compose will change this, but again, time will tell. ↩︎
Oh, the most recent app breaking change is the only one worth addressing? What about their decision to nuke their repo and leave their users high and dry? Then again that really wasn’t a breaking change, they just left. Their refactor in 2023 was the whole reason why the community repo was started. As for what benefit for TC? From glances at their discord, more people to abuse? lol
My config/data idea would be to have the questions.yaml have suggested paths for those very important things. In my case, I’ve done the next best thing, added the arr stack apps’ backup folder to a mount on my raid-z2 that also gets pushed to my gdrive.
Do you not see how much easier it would be for Truecharts users to migrate apps to community with that? Install, make setting changes, point app config & data from a different repo/train to some permanent storage… migration complete! Which is the whole point of this thread.
To address points 1 and 2 at the same time:
For single click app installation, without the need for helm/kube complexity, you’ll probably see the community repo explode in app availability. I’ll say it again, community and truecharts are not building their own images, those are done by other people. Why would you think any specific app would get out of date? Community, Truecharts, rolling custom apps or using docker(compose) are pulling those images from the exact same place.
I have not installed alpha (sorry, betas are feature complete, this one wasn’t) to see what the new 1 click install looks like. I’d be shocked if it’s much different than the current one. Instead of being ingested into helm/kube, they will either be done straight docker or use compose. Actually hope those command/compose.yaml are available to look at.
Can’t wait to be able to use gluetun/wireguard for whatever apps I want. I’m not going to learn helm templating and kube manifests to roll out apps that would be dead simple to do with docker.
Didn’t agree with it then, don’t agree with it now. Their stated reason is that they didn’t want more deployments (and therefore support requests) on an unsupported platform, which I can understand, but nonetheless think it could and should have been handled better. But there are at least a few copies of their repo around on Github, so it isn’t exactly hard to install new TC apps on SCALE if you want to.
I think what you’re trying to say is that you’d like app config/data to be stored in host paths rather than PVCs. Fair enough. They have their reasons, and I don’t pretend to know what they are. But getting the data out is still entirely do-able.
In the short term, perhaps. In the long term, well, that would depend on iX devoting sufficient resources to keep it up (because they manage the only catalog). Their record on that frankly sucks.
Well, with a Compose file, you can either specify a particular version of an image, or you can just call for latest. If you do the former, you need to update your Compose file whenever the upstream image updates. If you do the latter, you suffer whatever breaking changes may happen to the upstream image, generally without knowing about it until a user complains.
Both iX and TC, under k3s, have tied their charts to specific versions of the upstream images, which means the chart needs to update in order to pull an updated version of the image. What iX is going to do with Compose remains to be seen.
They push an updated version of the app.
The app has two versions, the underlying version of the container, and the app version.
So you click update or update-all when you want.
Which sets up a new version of the app. The old version is left behind so you can easily revert too
App breakage happens even with curated apps. With docker-compose, you’re cutting out the middleman.
For those that use the repo, creating templated configs for docker-compose will need much less expertise. For those that want to roll their own, you don’t have to spend a ton of time learning helm/kube.
Wonder how release canditate-y the RC will be.
