A lot of users have set up docker sandboxes, then “migrated” their TC apps to docker compose in those sandboxes.
Many of those same users have already now migrated those docker compose apps out of the sandbox to EE beta (and nightlies)
It’s not just new users, it’s just that a large chunk of TC users very quickly switched to docker compose when given the opportunity.
And I think that had a large part to do with it.
I was explicitly and clearly meaning having UI functionality for both K8s and Docker apps.
Neither:
bears ANY relationship to either:
Having parallel running of existing installed TrueCharts apps and the TrueNAS Charts apps that have been automatically migrated to Docker; or
Giving users who are non-technical and who installed many TrueCharts apps through a UI a nice uncomplicated, non-technical, ideally automated migration path to the new Docker-based solution i.e.
These users haven’t started upgrading to EE yet (which is why the EE Beta users are not representative of TrueNAS Scale users as a whole) but when they do I fully expect to see a shit-storm of posts on these forums asking for help because Scale offered them an upgrade to EE, and they clicked Yes without understanding that their TrueCharts apps and their configuration settings and any internal data was about to disappear in a puff of smoke.
I am technical and more than capable of doing the 3 stage transition from pre-defined TrueNas Charts & TrueCharts to bespoke sandboxes, and then to bespoke Docker apps and then to TrueNAS app catalogue Docker apps, but
See above for my prediction when non-technical users either decide to update from TrueCharts to Docker through a planned EE upgrade, or mistakenly get upgraded to EE and lose their TrueCharts apps.
I do think @Protopia has a point here, there will be some number of users who click update and find all their TC apps broken with Eel. Not everyone is on this forum, or even ever was on TV discord. To recreate those apps immediately (assuming they are needed immediately which seems likely) will not be good.
I kind of feel like the upgrade to Eel should come with dire warnings if TC apps are detected on their current system as a service to those users in an effort to help them resist the shiny new upgrade button on Dragonfish. Doesn’t seem like a big ask?
Why would you have to do things 3 times? Before upgrading to EE, pull your config/data out of TC apps. Upgrade. Install community docker apps or your own images and add binds for config/data.
Yeah, it’s iX’s fault that end users don’t read. You’re acting like iX has some sort of duty to migrate some other repo’s apps.
I do agree that iX needs some huge warning messages about the 24.10 update. Like gigantic. And links to generic instructions on how to get data out if they have TC apps.
IX has nothing to lose here, they get to pawn off the blame to a 3rd party by enabling 3rd party catalogs, what can go wrong. People rightly wanted Docker, so they get it, before they wanted app catalogs, now they don’t. It’s their company, their users
24.10 does include a rollback mechanism for App data. This was deliberately added for unsuccessful migrations.
We did reject that co-existence approach. It is very complex and especially difficult for new users. Mixing apps on both tools would have been almost impossible due to networking differences. At the OS level, Docker and K8s assume they have exclusive access to some resources.
Instead it was expected people who needed K8s to stay on Dragonfish until a migration path they liked was ready. Electric eel supports most needs, and Fangtooth will add extra capabilities.
Hi, everybody! I decided to join this lovely discussion after reading the first two posts of the thread.
Well, there’s always a rollback to the Dragonfish boot environment to get the TC apps back.
You have a point that BETA adoption rate is not definitive evidence about any specific reason for the upgrade. But three times the usual adoption rate suggest that there’s something special at play, and there are only two contenders to draw in the crowd: Raidz expansion and native docker-compose.
I’d say that one of the suspects is more of a plausible cause than the other…
The vikings coming onshore to raid to the tune of “YAML, YAML, eggs and YAML” may not be representative of the general user population (I expect that many want a ZFS NAS and do not care about jails, containers, or VMs of any kind). But if they outnumber the disgruntled TrueCharts users, iX did the right move. Lose some, get some.
Trigger Warning! You may be right in predicting that casual users will come asking for help after losing their charts to an untimely upgade to Electric Eel. And these users will then get a cold hard scolding for carelessly upgrading without first reading and understanding the release notes.
No one should ever jump on a release just because it is “the latest” release.
Fortunately, TrueNAS (and ZFS) provide an easy fix by reverting to the previous booting environment.
I’ll have your YAML. I love it! 
…so long as nothing in the upgrade process did anything to the apps, which has happened in previous releases.
In case of apps migration we’re cloning and promoting existing datasets from ix-applications rather than touching the old app data.
OR, people who insist on upgrading pools and not doing a checkpoint. I already see some on reddit wanting to upgrade their pools for new features.
TrueCharts have posted some information about migrating away from their apps if desired:
https://truecharts.org/news/leaving-scale
See also:
https://truecharts.org/clustertool/migrations/scale-config-only/
We’ve had about 3-10 people a day(!) asking about installing new App setups at the time we pulled that plug.
To give an idea: We still get 2 a week(!) this many months after.
We rather prevent damage, than to assist people in doing it themselves.
We would like to expand a bit on this:
What started out as a k8s-at-home fork (with the intent to upstream SCALE-related changes), diverged quite quickly with a major restructing refactor and afterwards even a complete rewrite from scratch.
Sadly enough it takes major work to make helm-charts play-nice with the SCALE GUI, leading to just about 20% of code being k8s-at-home related, even at the release of SCALE.
In the end leaving no original k8s-at-home code left, around early 2023 onwards.
So it’s not so black-and-white. You and @LarsR are both correct here.
Thats not the goal of using discord, but the same does also go for hosting a forum. Neither option prevents complete deletion, unless we want to give our soul to reddit or something.
We very-very rarely ban, instead we mute people so they can still read support resources. (first offense 1 day mute, second offense 7 days, third is permanent mute). We’ve actually never permanently muted someone on discord…
The only full-bans are reserved for obvious (crypto)spambots and at most 3 or 4 people that actually started verbally assaulting people (Like, harassing people in DM to call them all sorts of names, that kind of abuse)
Just to be fully clear here, we’ve discussed this with iX some time ago and all parties agree that this is a fine solution to the issue of people blindly upgrading.
Thanks for referencing!
While not perfect, as it doesn’t include storage, at least there is now a way of exporting the config that we can endorse and even provide some level of support for.
We hope this limits the use of all sorts of, often less than perfect, scripts.
If only…
There had been more openness at the time, explaining the rationale for iX dropping the Helm support without parallel running and TrueCharts explaining why they were dropping the catalogue without any notice period and indeed even explaining the conversations between iX and TrueCharts…
There had been a bit more effort to solicit input from the community before making these decisions…
then I suspect that a lot of community angst would have been avoided.
Communication and Openness are the keys IMO.
The reasoning behind it was publicly and clearly explained many times on our discord. The deprecation beforehand did not have the desired result (people not using the catalog anymore for new installs).
Whats there to explain? We were not involved in the Electric-Eel Kubernetes removal in any way. (besides 1 or 2 emails after the announcements to get a few technical details clarified)
Neither us nor iX can explain conversations that didn’t took place.
Its debatable if we should’ve.
The moment the announcement from iX hit, it was for certain that about 80% of our current users would stop using TrueCharts, as they where bound to TrueNAS SCALE.
It understandable that they would love to continue using our stuff for as long as possible. However, when that announcement hit, our question was “Do we want to still exist as a project in a few years time and how do we think that would look like”.
Gathering the opinion of users that are leaving way soon anyway, is not the highest of priorities when the future of your project is at stake.
Could it be handled differently? For sure!
Should it have been handled differently, on some fronts sure!
But that its debatable whereas asking for more community input was the best play.
We’ve always been 100% open about our reasoning and besides our infrequent news articles have frequent short announcement on Discord and staff to ask questions on plans. Which almost always get answered.
The only thing we are not open in are things like staff votes and discussions.
We’re so open (primarily on the discord), that we quite often get negative feedback when plans and timeframes change. :')
