Migrating from TrueCharts

TrueNAS General
,
61

On further review, this really seems like a red herring. EE isn’t going to include an “Easy Button” to move existing apps into k8s-in-sandbox, is it? If not, then TC needs to develop a migration path and tooling for that path. And unless I’m very badly mistaken, that’s going to end up being about the same amount of work (and yes, I realize “about” is carrying a lot of weight there). So what relevance do you see in the fact that TC could have planned to migrate into a different form of Kubernetes installation than the one they chose?

…which nobody knew until you mentioned it in this post.

62

“Dragonfish isn’t going away”… is as you quoted. We made it clear we were not forcing any rapid migration. We have users on TrueNAS 12.x still…

63

That’s a misread of what I said. I stated that K8s can be run in a sandbox and that therefore TC apps could be run on K8s in a sandbox. We were happy to work with TC on that process and provide a transition path. TC decided to choose another path (as is their right).

Staying on Dragonfish would have bought a lot of time for a better transition. There are no claims that it would have been perfect or simple.

64

I’d just like to point out that as we outlined in this previous news post (which I wrote), ClusterTool’s Beta includes SCALE app/chart migration tooling in it. Admittedly the current Beta version of ClusterTool has other issues preventing it working properly which the devs are aware of, but as far as the topic of supporting/enabling SCALE users to migrate to a Kubernetes cluster running on a Talos VM atop SCALE (our preferred solution) the capability has been there for months and guides/docs for how to do so and how to use ClusterTool are already up on our website in Beta form.

Dev work on CT has slowed lately, timelines have shifted and the scope of it has changed since its inception to the point where it’s unlikely I’ll continue to use a Kubernetes-based solution for my apps myself (I was going to be relying on CT to bootstrap my own Talos cluster and get the migration happening for me), but work on it is still continuing. I didn’t/don’t do the dev work on ClusterTool myself, but from what I gathered it was pretty easy to get the migration part of things going.

3 Likes
65

You must be relatively new, Truecharts broke every single one of their apps in Spring 2023. You had to either use a tool like heavyscripts/tt-migration or pull config/data yourself to migrate to their refactored versions.

No, that’s not right. I used migrate. It was DELETE THEN REINSTALL.

Which is when iX created the community repo. And probably no end to support tickets to deal with the mess Truecharts created. Would not be surprised if iX decided to move from k8s to docker shortly after that.

I’m sure that a lot of us actually chose Scale because of the work TrueCharts put into apps. But they have broken their apps from their own decisions. And the only people hurt were their users. They obviously wanted to get back at iX for the changes his year but nuking their repo was basically spitting into their users’ faces. I can’t imagine anyone wanting to be abused by them again. Or defending them for that matter.

Also interesting on how people want to decide how a company uses their resources. Maybe get involved with helping on the new app repo?

67

Then it seems to come down semantics. If TC had done nothing, people would still be able to install apps from their repository. They decided to remove that ability with no advance warning. I see that as breaking functionality that was there and would have continued to work as long as the user was running Dragonfish.

TC was a fork of k8s-at-home.
They took an existing base, expanded on it and called the result TrueCharts.

One could make the argument that you are gaslighting right now, because iX has not said or done thing things you are attributing to them. Repeating it many times does not make it so.

Clarifying, iX has not said that it’s all TrueCharts’ fault.

iX is removing the underpinnings that TrueCharts has relied on. TC was built on kubernetes. These two points are facts, and the decision to change was iX’s. This is not being disputed by anyone as far as I can see. Is it fair to say that it’s a decision that should be iX’s? I’d say so, since it’s their product.

Now what the TC devs did when that happened is a choice they in turn, own, using the same reasoning as above. They had other ways to handle it, but they chose to instantly pull the plug and went on to banning people on their discord who wanted to discuss the whole deal.

I’ll remind you that you are the one who just said these sorts of technological decisions are not black and white. I agree, they rarely are. Can you, in good faith, say that you judge TC actions here by the same standard as you do iX?

When I look at their respective ways of handling change I look at iX and see a dev team that sometimes has to make difficult decisions but when it comes to the apps, engaged with the community and eventually concluded that moving to Docker was the better choice. I suspect the status of some of the frameworks required by touted features played part in this, for example losing gluster. Still, staying with kubernetes would short term have been the easier choice, the one requiring less work. Even if I don’t necessarily agree with everything they do, I know I can discuss it here, in the official public facing forum.

Compare that to TC. The way certain TC devs (dev?) handles criticism, handles giving information and in general appear to make decisions based on emotion rather than careful afterthought. The fact that TC has built a tremendous apps catalogue falls flat when it’s governed in a way that make them extremely unpredictable.

Given that, the fact that they primarily use Discord makes perfect sense. It allows them to pull the plug at any moment and all information assembled there will be lost forever. It also means that if you get banned from the discord, their primary support avenue will be dead to you, you can’t even passively partake.

3 Likes
68

I probably should have been clearer; I recognize that at least much of the development has now taken place. My point was that, whether you’d chosen k8s-in-sandbox, Talos, or something else as your preferred migration path, you’d still need to develop that tooling if it was going to exist. Thus, I don’t see any point to the “TC could have used k8s-in-sandbox” argument.

:roll_eyes:

Yes, I know, though I think you’re a little off on the timeframe. I mentioned it in my earlier reply to you. I was assuming Neofusion was referring to something more recent.

…and people say I’m bitter.

…but you’re fine describing TC’s resource-usage decisions as “abuse” and “spitting into their users’ faces.”

Literally nobody is doing that. But it’d have been nice if they hadn’t gone out of their way to break a system that thousands of their users were relying on.

I guess. I think there’s an important difference between continuing to run apps you already have, and installing new ones.

…unless they ban you. It’s happened to me and others.

Because iX is so predictable, right? I guess they do give more notice, but…

…and that differs from this forum how, exactly? I guess this forum’s archived in the Wayback Machine, but…

1 Like
69

I am responding to what Captain_Morgan said, and he is an iX employee and so when he posts here he is being a spokesperson for iX even if he is not an official spokesperson.

70

Wrong - iX specifically provided support for 3rd party catalogues and apps and actively encouraged 3rd parties to create them because it benefited iX to have a substantially larger overall apps catalogue than they were prepared to support themselves.

Wrong - this would be true if iX was continuing to provide K8s runtime and administrative UI. Then you could certainly lay the blame entirely at TrueCharts feet.

But instead TrueCharts were encouraged to provide and support apps based on having iX provided the K8s infrastructure. It is a completely different ball game when iX suddenly remove all the K8s infrastructure.

Wrong - users chose to install TrueCharts apps ONLY because iX provided the K8s functionality and allowed 3rd party catalogues, and our expectation of support is that TrueCharts supports their apps and iX continues to deliver the K8s functionality.

Wrong - so so very wrong. If I swap your car for a lathe and say you can build your own, are you going to be happy?

Wrong - I expect iX to play fair - if they provide K8s runtime and administrative infrastructure, and encourage 3rd parties to offer K8s apps, and their users then use these 3rd party K8s apps, I expect them to provide a decent migration path including parallel running over several major releases and not to pull the plug without any parallel running capability.

If I sell you a diesel car, and then 6-months after you bought it I decided to support only petrol/gasoline powered cars, you might be a bit aggrieved that you can’t get spare parts or support from a franchised garage and that if you want to keep driving long term you need to change out your engine.

1 Like
71

Without saying too much and in an attempt to clean up just one of the nuggets of misinformation about the project, I’d just like to address the “their” from your post and point out that this wasn’t a decision made by the entirety of the project’s core team, and there was internal pushback against doing it. I myself merely maintain the docs side of things and don’t really have a say/decision in project-level decisions like that, however I explicitly was against removal of SCALE’s TC catalogue in its entirety. I’m a SCALE user myself, so this action directly impacted me.

I say this because I’ve seen other TrueCharts staff members on here and elsewhere be flamed by association at times, when it’s actually the case that some of us haven’t been anymore of a fan of changes that have been made than the wider community has been. Me personally, I love writing docs and stuff and that’s why I do it, but my level of know-how has always been limited to SCALE itself, associated Kubernetes commands as-needed for when I’ve needed to poke around under the hood of things, and not K3s as a whole.

Hell, I wasn’t even able to get apps/charts installed to and running on Talos following onedr0p’s cluster template guide. I know my limits, it’s why my NAS runs SCALE and why when this all blows over I’m likely moving to Docker. Should iX choose to discontinue support for Docker in another 3-5 years time when something else newer and shinier comes along, it’ll make portability and migration a breeze.

I’d also like to respond to this and say that while I don’t know personally when the decision was made by iX to switch to Docker (does anyone outside of iX actually know this?), you guys were engaged by us prior to the release of Dragonfish regarding shifting the responsibility of storage handling for apps via OpenEBS from iX/SCALE to TrueCharts using our OpenEBS storage operator app. This was due to issues with the specific versions being shipped by iX for use on SCALE.

Much, much work went into our migration process for Cobia → DragonFish from both a docs and a dev/testing/r&d perspective, and it was also very much a manual process that users had to follow. We’d have entirely not bothered spending volunteer manhours on this had we known prior to the release of DF that the plan was to move to Docker. I personally find it hard to believe iX hadn’t already decided to make this move.

We didn’t get any notice either.

Fair enough.

1 Like
72

This entire thread is weird to me, why are we still talking about TrueCharts and K8s? Where has it ever been implied that we supported K8s and would support 3rd party catalogs in any official capacity? Does nobody remember the BIG scary warnings in the Docs as well as UI that appeared whenever you used 3rd party K8s’s repos?

image
image1035×800 60.1 KB

We made the decision internally (shortly after Dragonfish was in code-freeze) after seeing the mess of issues directly related to using K8s under the hood, and the fact that at every turn we had users, asking and begging us for just regular vanilla Docker support. Based on the huge turn-out we’ve seen in BETA1 adoption of Electric Eel with Docker (3x a previous all-time high record) I think we made the right call for the vast majority of users.

4 Likes
73

I take it as an indication that iX primarily thinks of TrueNAS as a storage plateform; app functionality, while desired, is not fully considered as a “feature”. That fits with the record of allocating little ressources to developping the app catalog (plugins), yet not being ready to hand over control to third parties, including the community.

k3s and docker-compose already coexist in a SCALE version: Dragonfish, with compose in a sandbox. Admittedly, one has to install the sandbox, but that is FAR easier than installing omv-extras and then the docker pluging in OMV, to use the competion as a benchmark.
Migrating from TrueCharts to “own k8s in a sandbox” and then to (native) docker-compose makes no sense when one could migrate straight into compose: The biggest chunk of complexity is in the Kubernetes part.

The key point is that no user of Helm charts is compelled to migrate out of Dragonfish as soon as Electric Eel is out. And it looks like it’s worth repeating it.
As for re-running the old debate, this is unlikely to change anyone’s mind on any side of the divide.

2 Likes
74

Thanks for this insight.

It’s entirerely plausible that the move was decided between Dragonfish and Electric Eel, just like the decision to move sandboxes to LXC as early as Fangtooth was taken around the time that Electric Eel was frozen. iX is moving rather swiftly to see what works best.

3 Likes
75

Good mention of that warning from kris Migrating from TrueCharts - #72 by kris

You bought car that was able to run on diesel but dealer said to you that diesel is not officially supported, it can stop working any time and you need to service it yourself.

You still bought it and it stopped working as you were warned. And now you act surprised?

But either way we are all beating dead horse here.

76

Either way, they still did. They also did the refactor in 2023 that forced users to use migration tools to reinstall apps. With those 2 actions, I would question the sanity of anyone who wants to continue to use their platform.

I’ve also given props to the TC people for their hard work. They added a lot of value to Scale. But people in control with TC decided to lash out at iX but only hurt their end users.

@dan Common Porting Progress | TrueCharts Charts

Just in case you weren’t using TC apps in spring 2023. Add that to nuking their repo, which really only affects their end users. Shows how much they care about them.

77

The catalog removal was because people were still coming to install obsolete apps, existing users were fine, and depending on someone that will be deprecated in a few months wasn’t great.

Honestly the removal didn’t benefit anyone, and people who use TrueNAS will just move on anyways, if they really want Helm Charts they’ll run them, iX wants whatever, so if people want to run what’s supported then they’ll just have to stick to their stuff. Running hacky Sandboxes that may disappear or break with a future iX isn’t a long term solution for serious app users honestly.

1 Like
78

Were those apps obsolete yet? If they were, how did Truecharts expect their users to update? Without their new system, they basically left everyone in Limbo.

If you want longevity, run containers on a different OS. In Scale’s case, the move to Docker should have some best practices guides to allow you to easily migrate your app config/data. As in create Datasets for that purpose and learn where each app expects those to be mounted in their container(s).

I did poke around my APP drive, looks like community apps do have config/data broken out, but I don’t think they would survive app deletion. I’m already planning on moving that stuff into a new Dataset on my Apps drive or to my main storage. That way if things change, it will be easy to get things working on whatever platform I choose.

Getting back to the thread topic, is it even possible to create a catch-all guide for getting data out of Truecharts apps? Simple apps like the Arrs/plex/downloaders are relatively easy (specially apps that have built-in Backup features). That’s probably not the case with many apps?

79

I’m aware, I had been a TrueCharts user for some time at that point however wasn’t part of the team. As alluded to in the news post you linked, SCALE compatibility was a sizable portion of the reason the common rework needed to happen, and at any given time was responsible for a third or more of total project dev time spent (to maintain this compatibility).
As Steven mentioned above, the people actually devving for the project didn’t deem it necessary to continue to spend this large amount of dev time on what was a now dead-end platform. There are many reasons why this is both good and bad when it comes to software in general.

It’s not like some users have an option. I myself would run all of my apps from iX’s catalogue if it actually had all the apps I use in it, but if there’s some obscure app that our catalogue provided the ability for you to run on SCALE, and you weren’t familiar enough with alternative ways to deploy apps (e.g. using the custom-app button or setting up a VM or something) then you were SOL as far as alternatives go. This forced both myself and other TC users to become familiar with things we’d never touched before, and I’m glad I got the opportunity to learn how that aspect of things worked.

As other users in here have already said, our catalogue provided a relatively simple way to run apps/charts that iX themselves didn’t provide, on SCALE. I’m not saying it was without fault, but it’s been my experience that SCALE attracts some users who think they know more about things than they do, yet still rely on solutions like a completely GUI-based bridge like TrueCharts to allow for them to use SteamCMD to run a game server right from their NAS at home. iX’s catalogue doesn’t even have something basic like this in it, unless SCALE’s Applications → Discover page’s search that I’m using is broken.

Depends what you define as obsolete. As the weeks/months rolled on, more apps became outdated or vulnerable to high-severity CVEs like Homepage had. The vast majority of apps however would/will run fine almost indefinitely on their last-shipped versions.

iX is free to do that for SCALE, they already have extensive documentation for SCALE and all its features, however I suspect they don’t see the need to since their apps use HostPath and not PVC storage. TrueCharts won’t do this for a number of reasons including not having anything to do with Docker as a project and, from our perspective, SCALE as a platform being deprecated (so none of our time is spent writing docs for it, as an example).

That being said, we do welcome community contributions to our docs and as docs maintainer I wouldn’t reject any PRs from someone wishing to add instructions on how to migrate their TrueCharts apps to a Docker-based environment, unless instructed otherwise.

I have a bit more than 20 or so apps from the TC catalogue that I’m running on SCALE, including but not limited to the 'arrs, all using PVC-based storage and I’ve been able to use HeavyScript and WinSCP as mentioned in a previous post of mine to pull the data out of all of them. In the past I’ve also used the exact same method to move from HostPath to PVCs by having the apps create the PVCs, stopping them, copying the data into the PVCs and then starting the apps again, also without issue. This also extends to using VolSync to backup said PVC data to S3/B2 storage, which I setup in preparation for the move to Talos (which I’m likely no longer going ahead with).

Our docs also have methods for extracting and manipulating databases inside apps as well. Granted I personally don’t run something as complicated as like NextCloud, so I’m not sure if the same processes that work for me also apply to there.

If you’re already using HostPath for your app storage though, be it with an iX/TrueNAS-provided app or TrueCharts, you shouldn’t have to do anything as far as config/data storage is concerned.

Anyway, it wasn’t my intention to drag this thread off topic nor to have it devolve into who provides a better solution. Merely, I guess in this sort of… sunset phase, to try and clarify some potential misinformation that has been going around and to try and quell the opinion that TrueCharts members as a whole have a disregard for users whether our own or SCALE’s. That fake Reddit AMA on the TrueNAS subreddit certainly didn’t help things.

3 Likes
80

In my case, I just brute forced things. Why get cute when 25+ years of unix experiences led me to an easy for me solution. Add extra mount to each app, copy data out, uninstall, reinstall then push the data back in. Using Heavyscript is probably the more elegant and superior way tho. With the Arrs, using the built in backup feature and mounting that with hostpath, would let you do a simple restore as well.

Now that I have more docker experience, I’m going to properly treat apps/containers as disposable while having the actual useful data in places that is not. And I think that’s a takeaway everyone should consider.

4 Likes
81

I really regret that this whole can of worms has been reopened again, but I cannot sit back and let claims from iX go unchallenged.

Where in those warnings does it say don’t use TrueCharts because we might remove the K8s technologies that they rely on and that we encouraged them to use and if we do that then you won’t get support from them?

Having new regular Docker support does NOT imply withdrawing K8s support and withdrawing K8s support does not mean doing so in such a brutal fashion. These are all separate things.

Again this is fallacious logic and / or misuse of statistics. The Beta1 adoption are likely either new users or those courageous enough enough to migrate their production servers to a Beta and technical enough to do this app migration and enthusiastic enough to do a migration several times. In other words, this inference is based on a statistical population that is quite likely NOT representative of TrueNAS users as an entire population.

Only a few users think that implementing Docker support is a bad thing.

Many people would agree to K8s support being removed in due course.

But the evidence you claim here to demonstrate you made the correct decision is NOT actually the case. Of course these users will like the new Docker support - they are the ones who explicitly want to use Docker despite the early nature of this version. That does NOT make them representative of the TrueNAS Scale user population as a whole.

But those users who have a lot of TrueChart apps installed have had their trust in iX badly broken.