I’m confused by this sentance, can you please explain?
With docker compose, you the user are taking on the risk of breaking your app. Whereas package or app maintaners do this on your behalf. Isn’t that offload of risk preferable for 99% of people?
In the example of the Dragonfish to Electic Eel migration, iX had their own seamless migration baked in, and TrueCharts came up with migration paths as well. No matter which camp you were in, there is at least direction.
There’s a reason why there are issues/tickets for community/truecharts or any other project that tracks issues. Things break, either from upstream images or the main projects themselves. Rolling your own apps means you get to make the decisions that work for you.
If you want to run 1 click install from a repo, more power to you. Honestly, it’s probably not going to be much different under the hood than doing things yourself. They will be using docker-compose just like anyone rolling their own.
Wouldn’t be surprised if 90% or more (prob 99%+) aren’t building their own containers, so everyone is going to be using similar dockerhub projects that already have docker run or docker-compose examples. Also all kinds of web tools to convert docker run commands to compose yaml.
Just looked at truecharts’ migration tool:
Will ClusterTool migrate my application data to Talos?
No. Talos will only migrate the actual application/chart itself, not the data associated with it. Data for applications/charts that you would like to be migrated to Talos also, must be backed up to S3/B2 storage prior to migration using VolSync as described here.
So back to the topic of migration of truecharts config/data, people are going to have a crash course in figuring out how to pull that out of truecharts apps to get them working with Scale or over to Talos.
For simple apps like the arrs/downloaders/plex, it can be done either with something like heavyscript to mount volumes or end users can just add an extra mount to apps, shell in and copy data out of the app.
With more transparent/explicit config/data locations in the App UI (like you’d have with docker), many would be trivial to migrate. Bind the same paths for config/data to the new one. Done.
it wasn’t “sudden death”. We announced Docker Compose 6 months in advance and have no plans to prevent users from continuing to use Dragonfish and K8s. We planned for an 18 month transition.
Docker and K8s can’t run in parallel except as VMs or Linux Containers. For that reason we supported Sandboxes in Dragonfish. You can run either K8s or Docker in the sandbox and still access all the files in ZFS.
TrueCharts could have migrated to a Sandbox with their version of K8s. They chose not to, that is their choice.
TrueCharts decided to stop support on Dragonfish… they had another year, but chose not to give their (and our) users advanced notice.
My suggestion is that its more efficient to discuss independent development of specific features or applications that TrueCharts had rather than the generic migration of all Apps. The latter would require a copycat approach which is ethically questionable.
Electric Eel is feature complete this week. Most of the base Apps can now migrate and that will be complete by November. The Docker Compose infrastructure and YAML editor are now usable. Dockge and Portainer are usable. The Community can now build Apps that are powerful… so its time to start innovating.
These arguments from @Captain_Morgan are simply reigniting a debate that some of us had put behind us because they are completely lacking in any empathy for either users or TrueCharts as well as being somewhat disingenuous and gaslighting.
As Jack Reacher said: “Remember, you asked for this.”
A very trivial point, but actually four rather than a couple.
It is sudden death in the sense that there is no release where you can run both existing Charts and Docker Apps in parallel in order to migrate app by app whilst having everything working. You have working TrueCharts apps on Dragonfish, you do an upgrade to EE and suddenly (like a bat out of hell) they are gone gone gone. If you didn’t make a note of the details tough. If your data was in an ixVolume, tough. If it takes you 10 weeks to create a Docker version, tough.
So Docker and K8s can run in parallel if in EE you put Docker inside a Linux container, and then in Firefish (or whatever 25.04 will be called) you dropped K8s and moved Docker native. But you chose not to do it this way (presumably because it would be a lot more effort - which is a powerful reason but not a complete showstopper as you suggest).
Instead you expect Dragonfish users (esp. non-technical ones who used a GUI to install TrueCharts) to migrate apps themselves to Sandboxes + installing Jailmaker and Docker all through a CLI.
And then you expect them to migrate again to EE Docker. Not exactly user friendly is it?
OR…
You could have kept EE on K8s and developed the Docker-based solution in parallel and once it was feature complete, offered it as a technology preview alternative version of EE, thus genuinely allowing 6 months until TrueNAS “F” actually switches to Docker in production.
There were other options - but iX chose to go down the sudden-death switchover route.
Ah - so your defence is that TrueCharts are the bad guys for throwing their toys out of the pram after iX had encouraged them to create a K8s Catalogue and they invested a lot into creating a K8s based infrastructure, then suddenly iX announces that K8s was going to disappear without a parallel migration path?
Yes - TrueCharts could have acted better, but it wasn’t TrueCharts that precipitated this.
As for suggesting that they migrate their Apps to Docker:
Based on TrueNAS committing to K8s, they committed to K8s, and then supported other K8s platforms, and you are suggesting that they now support Docker in addition just because you decided to abandon K8s? Are you going to pay their costs for that?
Without tools to allow configuration migration from TrueCharts to a docker version, not exactly possible. Are you making the Charts → Docker migration tools available, and is the documentation of these tools yet available? You cannot realistically claim to have given them 6-months notice to migrate if the tools and documentation are only just available this week.
If we are going to start considering ethics…
It is not ethically questionable to assist users that iX encouraged to use TrueCharts. It is not ethically questionable to use the same publicly available docker images as TrueCharts does.
What is very arguably ethically questionable is encouraging TrueCharts to invest in providing a K8s-based Catalogue and then leaving both them and their users high and dry!!!
So is it feature complete or are some features delayed to November or even later if at all? It cannot be both.
I’m not certain, but I think this is the first time I’ve heard that figure mentioned–all I remember seeing before was “Dragonfish isn’t going away,” leaving details very vague about how long it would be supported.
Sure, and let you pull the football away yet again. I wouldn’t have in their shoes. And that’s ignoring the technical merits of each course of action.
You can’t not know this by now, so why are you asking yet again? Seriously, look at the TC apps–any of them. But I’ll hit a few of the high points, mainly the ones I’m using:
Traefik integration
This doesn’t just mean “Traefik is available as an app,” but that when I install, say, Sonarr, I can check a box to enable it, enter a hostname, and everything’s configured, including TLS.
VPN integration
As above–you can fill in a few fields, and the app in question will communicate over the VPN connection
TrueCharts (K8s@home) were already using K8s before TrueNAS. TrueNAS (dragonfish and electric Eel) provides a way to run K8s with Sandboxes. Dragonfish continues to run with Kubernetes and will do so for quite a while.
So… I’m arguing that “high and dry” is emotional and not a technical analysis of TrueNAS status. That TC stopped supporting TrueNAS users is not something we have control of. “high and dry” applies to that action.
As indicated in discussion with @Stux - there is a focus on providing the necessary tools to build the Apps that people want. However, there is not a focus on copying/replicating the TC catalog. So, its better to focus on specific needs.
What are you talking about? He made one (1) reply after 7 days in an otherwise active thread and he is the one reigniting the debate? Would you rather have iX say nothing at all?
Seriously?
So, a TC issue, it was going to work like that until they had an angry moment and pulled out.
You’re demanding that iX supports two concurrent Apps frameworks but don’t leverage similar demands on TC, arguably the party in this that actually pulled a “sudden death”, withdrawing support and actively breaking things with no warning what-so-ever?
It would be, if iX copied TrueCharts work and slapped an iX label it would definitely qualify as unethical.
As far as I can remember, that TrueCharts+iX soured more than a year ago, the writing has been on the wall for quite some time. Not sure what kind of recent “encouraging” you are referring to.
Okay, I’ll bite. Why can’t it be both?
Why can’t their initial plan of what the Docker transition will be be “feature complete” while realising that users like you and me request more features and plan to add those when the time comes?
True… we left it open. It depended on how quickly we got to feature parity with quality. We had zero intention of forcing people to upgrade to a release which was of less utility/quality. We estimated it would be done in less than 12 months, but we had to anticipate it might take longer. We also committed to keeping K8s possible within a Linux Container (sandbox).
Right. They should have continued to fully support a platform that could not continue past the current release, while at the same time developing a migration path from that platform to something they could support.
Part of your stated reason for the move to Docker was that it was too hard for your paid, full-time staff to maintain the 15 apps (+ 2 enterprise apps, which duplicate two of the 15) you’d managed to create. TrueCharts–all volunteers–have nearly 800. And you think they should have taken this on as well?
And further on the Sandbox idea–aren’t those going away in favor of LXCs?
iX has paid, full-time staff; TC doesn’t.
What has TC broken?
iX specifically allowed third-party app catalogs in SCALE, and at least at the outset, didn’t give any kind of warning about them. They also had a very limited app catalog of their own. Both of these facts encouraged the development of a third-party app catalog.
(initially missed replying to this)
True, due to their Enterprise side. The apps are mostly intended for their community edition though, which doesn’t directly contribute to their salaries.
I can emphasise with being hesitant to support two concurrent layers that aren’t going to be equivalent feature-wise. It sounds like a nightmare from a support perspective. SCALE vs CORE is enough.
The last thing was moving their repository.
That’s a fair argument.
The catalogue would still work in a configuration with jailed kubernetes. TrueCharts chose a different path.
As can I, but then that argues pretty strongly against the idea that TC should be going even further out of their way to support a platform that’s giving them the boot–especially when they don’t have paid staff to do it.
So then no, they haven’t broken anything. They’ve attempted (not all that effectively) to prevent new installations, but everything already installed continues to function. And if you do want to install a new (or reinstall an existing) TC app, copies of their repo aren’t hard to find.
I agree in not liking their decision to pull their repo. I can understand a desire to prevent, or at least minimize, new deployments on an unsupported platform, but still tend to think it could have been handled better. And tact isn’t their strong suit.
Perhaps, until iX does something else to break it again. But nothing’s stopping users from doing this if they choose.
To be clear, I’m not claiming bad faith on iX’ part. But this isn’t the first time they’ve made changes that have broken TrueCharts, so for that reason alone, I’d be very reluctant to choose that route if I were in TC’s shoes.
It’s a bit like “apps” being transitioned to docker from k8s.
Obviously, I can’t speak for iX, but I can say that LXC is a more featureful technology than Jailmaker, and iX have indicated that they intend to adopt LXC/Incus as the future of Sandboxes for TrueNAS.
This should provide a good migration path for “Scale Jails”, with a better result in the end.
Meanwhile, IX have built a good app system with EE which delivers most of the benefits of k8s charts, without the costs, but may take a few cycles to reach feature parity with where apps were on Dragonfish.
So that’s a “yes - not yet complete” then, since being able to bind an IP address in the App Catalogue infrastructure is (somewhat obviously) a feature.
I am not sure how your response is any sort of debate about ethics.
The fact that TrueCharts existed and used K8s before TrueNAS is irrelevant from a user perspective. iX encouraged app catalogues and TrueCharts responded and then users used TrueCharts. That was entirely down to TrueNAS and iX enabling and encouraging 3rd party catalogues.
TrueCharts invested a LOT of effort into supporting TrueNAS catalogues and TrueNAS users, and you absolutely left them and more importantly thus TrueNAS users who use TrueCharts high and dry. You cannot gaslight your way out of being responsible for this.
As I said before, I do agree that TrueCharts abrupt cessation of supporting the TrueCharts catalogue and TrueCharts apps was not a good action. BUT…
That was a reaction to what iX did to pull the rug out from under them.
Just because their reaction was poor IS NOT an excuse for the way iX has behaved. Attempting to put the blame entirely on TrueCharts is unworthy of you.
As you should know full well, I have absolutely NOT been advocating for iX to replicate the TrueCharts apps. I have made it perfectly and unambiguously clear that I see this as a community responsibility, and so it is absolutely implied that I agree that iX resources should be focused on providing the tools.
You are arguing that it is a TrueCharts responsibility and that they have already had 6-months (or was that a year?) to do this, yet you admit that your implementation is not yet feature complete and that the documentation isn’t yet available, and I am not yet clear whether community submissions are open or whether iX has the resources to process the flood of PRs which would appear if TrueCharts did create Docker app versions, so I cannot possibly see how you can at the same time claim that TrueCharts have had 6 months to produce a Docker-based set of equivalent apps. This argument is a logical absurdity, is self-contradictory and IMO is neither an explanation nor a justification for the way iX has behaved.
Yes - as I said at the start of my rant, I had put the issues over the decision and approach to switch to Docker behind me until the subject was raised again, and if you accept that this decision is a done deal, then I would fully agree with @Stux 's statement.
If people stuck with focussing on the positives, discussions around blame would not have appeared again, but if iX are going to reopen the debate about the decision again and then claim that they were as white as white, then I am going to present the counter-arguments.
Truecharts did not exist before Truenas, the main developer is afaik a k8s developer and started Truecharts as a side project because the official apps were lacking in features and there were only a limited number available. He started Truecharts somewhere around the late alpha/early beta phase of scale if my memory is correct.
I would rather iX NOT claim that they are whiter than white, that this was the only possible course of action, and that for users who are in a pickle because they followed iX’s support for 3rd party K8s catalogues this is entirely TrueCharts’ fault and that only they are to blame.
These sorts of technological decisions are not black and white - they are nuanced, needing to weigh up not only the technical pros and cons of options, and the effort required to implement them, but also those on 3rd parties (users and TrueCharts) who made investment decisions based on iX’s previous recommendations. And I am sure that iX management did indeed take these into account - and though some of us might have disagreed with the weightings they gave and the end result, iX has to fund the development and make it work technically.
So I would guess that there is a justification that iX could present as to why they made the decisions they did - but instead they have apparently chosen to present their decision as the only possible one, and it is ONLY TrueCharts that is to blame for the consequences on users, and IMO this is simply not true, and needs to be called out.
It was NOT me who made the claim that TrueCharts pre-existed TrueNAS support of 3rd party catalogues. I was simply saying that even if it were true, it is NOT an excuse for iX to pull the rug out from under them.
Exactly - and this is why iX is, to a large extent, responsible for users having TrueCharts apps and for TrueCharts pulling the plug (and for the record whilst I might understand why TrueCharts pulled the plug, I don’t like the way they did so).
{humour}
To partially follow the internet culture (i.e. all debates eventually end up discussing the war - but only partially because I am going to use a different war than WW2), this is a bit like saying that the Russia / Ukraine war is Ukraine’s fault. After all they could just have lived with the situation and adapted, or they could have migrated to Poland rather than starting a war, and indeed Russia gave them over 7-years warning of the need to migrate to Poland when they annexed Crimea in 2014. Clearly Russia is not the one to blame here - the Ukrainians shouldn’t have chosen to live next door to Russia if they didn’t want to have to migrate.
I previously suggested that you could have run the new Docker apps in a Linux container in EE to allow at least one release with parallel running, but of course equally…
iX could have moved the existing K8s functionality into a Linux container in EE and run Docker native.
Committing “to keeping K8s possible within a Linux Container (sandbox)” is not exactly friendly to less-technical users who have TrueCharts apps installed through click-to-install, and who are now being asked to learn all the technical stuff needed to:
Create K8s in a sandbox;
Recreate from scratch the TrueCharts apps they previously installed through click-to-install.
Do all the above AFTER they have migrated to EE and their TrueCharts apps stopped running.
If running K8s in a Linux Container is so easy, then why not keep the existing K8s admin functionality, move the run-time into a Linux Container (so all existing apps continue to run - perhaps a little less efficiently but they work), and then add the Docker functionality natively alongside the K8s functionality?
Clearly there were more user friendly technical options, but iX chose not to implement them. There were probably reasonable reasons for this (technical or due to costs/effort), but if this is the case, then iX should present those reasons rather than attempting to put the blame onto TrueCharts for a situation that iX created.
