Good luck!!
Filler, filler
1 Like
My thought was similar a few years ago, but instead of VM, it was all custom apps, so, did that in Kubernetes times (pre Eel). Those custom apps always ran, ran the way I wanted them to not the way the app creator made them and their assumptions, and I do not have any issues ever, updates are flawless (just look at all the nextcloud posts, mine do not do that!). With Eel, instead of just custom app, I have created compose yaml. And, as you say with your VM, no matter what IX does it should work (just like it did before). Unless they remove docker. In your example, they could remove vms, lol!
You are using dockge which is fine, you won’t (for now) see them on the apps screen. I won’t use anything, just the UI. But either way, I expect all will be well from here on out once we all get over the migration. Docker is transportable to just about anywhere so I see little risk moving forward. Hopefully, the last time for major pain.
1 Like
Yes - I have always believed that Docker is a better solution, however the process of switching from K8s to Docker is going to be more painful for some than it needed to be - but once we are all switched over, I think it will be great.
1 Like
Its not our goal to provide any form of “kubernetes 101”, its not our strong suit and we barely have the manpower to provide documentation for our tools (In a lot of cases even that documentation can use some work).
There are docs, tutorials and YouTubers that are more qualified to provide that content than we are at the moment.
Thats also why we’ve clearly communicated that the target audience for clustertool has changed to "Users who know how, and are willing to, maintain their own kubernets cluster.
As we dont think the average SCALE user, is a good fit for maintaining their own kubernets cluster at all.
Simply put: ClusterTool is there to make some frequent tasks easier.
But thats the scope of it.
On nearly every blog we post:
We recommend users review the TrueNAS Software Status page for advice.
Keep posting it yourself, it’s the way we get the word out.
If anyone disagrees with the recommendations, we welcome the feedback.
In a round-about-way I was trying to say:
I have the ability to (and have) ripped the head off my setup. KISS, because if more people start evaluating what is more and/or less important to them instead of trying to assign, define or align with your version of “better”, maybe they will start ripping too–and XYZ then becomes obsolete. So whether you’re a dev or a power user seeking fame and glory; ultimately one person’s solution or setup may not be the best (for me or anyone else) but if you truly want to help people, write documentation/scripts/etc. to offer people a choice or educated guess.
Whenever I hear a developer say that something like documentation or “this or that” is too hard/long/etc. I remember something one of my mentors said to me, that stuck with me: “STFU”.
OK, here’s some (blunt) feedback as requested:
-
You should link to the Software Status page on the UI update page;
-
You should provide a dropdown to allow a user to define what type of user they are from an upgrade perspective which would limit upgrades offered to those appropriate to that type of user;
-
You should be much more explicit in your announcements about the types of users who should upgrade and not just give a bland link to the Software Status Page;
-
You should stop making the only measure of the success of a release the total number of people who have installed it, and start breaking this down into successful and unsuccessful upgrades and by new installs, upgrades from betas/release candidates, and normal upgrades (and if you have the above suggested dropdown of user type) by this user type;
-
You should be more open to listening to advice and warnings given during the release development e.g. that many users will upgrade too early and without planning and that better warnings are needed;
-
If you are going to do anything that risks stuff not working afterwards or that requires users to take preparatory actions, then you should do a pre-upgrade sanity check and warn the user if any part of the upgrade is going to fail and break something;
-
Specifically for EE upgrades, you should be providing blunt warnings about the need to prepare carefully for app migrations on all the Announcements and on the UI System Settings/Upgrade page;
-
[EDIT: Blurred as this was incorrect and an additional pointer has been added - click to see the original] You should change the Release Notes page to be much more explicit that apps from 3rd Party Catalogues will not migrate and the user will need manually to create a replacement; and finally
-
It is my view that software should only be considered ready for a full release when it is suitable for use by Early Adopters, and you should delay full releases until this is the case. According to the Software Status Page you linked to 24.10.0 is NOT even suitable for Early Adopters who should remain on 24.04.2.3, and since you state it is only suitable for “Testers” that clearly suggests to me that this software is still in a test state and not ready for release. (I would only ever expect Betas and RCs to be in the Testers row.)
Edited: To blur a factually incorrect suggestion.
Read your first post here:
Where does it say anything other than we have a great new release, it’s got all these shiny new features, it’s stable, so implied is update now! Heck, it’s even “polished”. Nothing to indicate maybe wait a bit, etc. Same was done elsewhere on reddit. Simply not the case. Maybe there are places you posted other stuff, but, this was the main announcement.
I do think you should do better on these. Also, nowhere does it mention (look at it right now) even if you did post a link to the osftware status page that it is expected that 24.10.2 would be the conservative update. It’s not there yet, and I don’t know if people understand that table anyway or would read it.
I have been reflecting on the posts in this thread by iX and the responses by myself and others.
I am not party to the mass of internal discussions that will take place between iX senior management to determine whether a TrueNAS version is ready for release…
However I am definitely being left with the impression that marketing (delivery to a pre-determined schedule i.e. 2024-10 release before the end of October, rah-rah announcements, over hyping the readiness of versions for normal non-technical users, not publicising the risks, not developing safety-related code) takes precedence over ensuring users are properly informed about the risks of upgrading and the pre-requisite actions that they need to take and helping users to avoid making uninformed mistakes - and the consequence of this is already becoming clear for users who have upgraded and then found their apps are broken.
As I said, I may be wrong, but if marketing is taking precedence over safety, that is a sad situation.
(I’m responding just to this one item not because there’s nothing valid or appreciated in the rest of your criticism, but just to clarify)
There is an explicit statement of this in the Upgrade Notes (and it was already present in your screenshot earlier in the thread). As of this morning, there is an extra sentence added to the first list item to clarify and direct readers down to the existing row on the chart.
1 Like
@Protopia , for the record, none of my apps are on TrueCharts. When TrueCharts dropped support for TrueNAS Scale last May/June, I promptly uninstalled the TrueCharts versions of Audiobookshelf and Kavita and reinstalled from IX. Thankfully, Audiobookshelf has that backup feature while Kavita was a minor reinstall as I had not read any books yet. The third, Calibre, was a “nice to have app”.
It should be noted that when I asked when the latest version of Audiobookshelf would be available in the TrueCharts Discord channel as my first post, I was pointed to the announcement and was promptly muted for 24 hours for violating the rules. That was my final port as I dropped that channel. As they say, life is too short…
Everything else has been on the IX store.
Apologies - you are correct that there was a section on third party catalogues later on which was indeed in my screenshot. And I think the extra sentence you have added helps to highlight this.
1 Like
My TrueCharts apps are also limited and non-essential. I have always believed that there will be more stable support for 1st party apps than 3rd party apps, and so where apps were in both catalogues I always chose the TrueNAS Charts versions rather than the TrueCharts versions.
This is NOT to understate the usefulness of the TrueCharts catalogue - it provided many many more apps than the TrueNAS Charts catalogue (which was I think the purpose/benefit of iX allowing 3rd Party Catalogues).
So from TrueCharts I have only OpenSpeedTest (to occasionally test the end-to-end bandwidth between my laptop on Wifi and TrueNAS - which I can definitely do without), and syslog-ng so the server can act as syslog for all the other bits and pieces on my LAN (and I no longer really monitor these logs anyway).
But I will wait to see what the issues are in the first few weeks of 24.10.1 after it comes out in a few months before deciding whether to migrate or wait further. (To say I am cautious is an understatement. I am definitely NOT an Early Adopter or a Tester.)
1 Like
Ironically I would never have run TrueNAS SCALE up to today if TrueCharts had not existed.
The single most important “app” that is not easily deployable on FreeBSD for me is Onlyoffice Documentserver.
I know a port now exists but it’s far from “click and go”. And I am only interested in using it as the “Office engine” for my Nextcloud.
I have moved Home Assistant and Flame to iX apps and then installed Dockge for Onlyoffice, Peanut and Uptime Kuma.
So I am still running SCALE and I am intending to migrate one particular friend from CORE to SCALE, because the “app” experience is the most important feature for him and Home Assistant and Paperless NGX are readily available.
Personally I will keep running everything that can run in a FreeBSD jail easily running in a FreeBSD jail. If that means replacing CORE with stock FreeBSD and Ansible, so be it. SCALE is an additional option for me, not the core (ha!) of my infrastructure.
I think EE is a solid product and as I said I am going to recommend it. It’s definitely better than e.g. Synology or other commercial NAS plus apps things.
Kind regards,
Patrick
3 Likes
Despite my critical comments, I am overall a big fan of iX and TrueNAS - for more than a decade iX has not only been delivering a solid NAS with masses of extra functionality, but it has made massive contributions to a lot of underlying technologies (like FreeBSD and ZFS) without making a big fuss about that.
And I have no doubt that the Docker-based app infrastructure is at its core a solid long-term development and in a couple of years the pain of migration will be forgotten - but right now I foresee quite a bit of pain as users find their apps broken after migrating.
If the whole product was a flaky mess, I wouldn’t be using it or bothering to make a fuss - but normally both their product and their support is absolutely brilliant, which is exactly why I think it is a pity that iX are letting themselves and their users down by creating more pain than necessary for the switch from K8s to Docker. It is probably too late to make changes to avoid much of this pain, but I think general lessons can be learned to avoid similar difficulties in the future.
1 Like
I looked at the TrueCharts catalog, and I might as well be looking at a geek’s version of a toy catalog. However, I’ll go with Proxmox for now and learn from that.
Funny thing, neither are actually first party apps. Unless you mean single click install repos. I don’t think official, community or truecharts apps are creating their own images.
I don’t think anyone would deny their apps being a large draw to Scale. But they shot themselves in the foot with their refactor that meant all apps had to be deleted then reinstalled. Then they spat into the faces of all their users when they nuked their repo.
I would imagine all the TC repo (and official/community) apps would be using container images on dockerhub or another public container repo. And those dockerhub projects would all have sample docker run and/or docker-compose examples.
I’m very happy with EE. Docker-compose is about 100 times easier to learn than k3s/helm. Already rolling out my own apps without being exposed to truecharts toxic discord. I still need to decide on whether to go custom apps for everything or not.
1 Like
Thank you.
Yes, we’d like to add it to the Download Page and the Update page.
Its a recent innovation and we were waiting to see that it was successful.
Not so sure…we’d have to automate it and users can wrongly classify themselves. Has anyone else managed to do this?
We’d really prefer users read the release notes 1st.
No, we can’t do this. We really don’t know the quality of a particular version for 1 - 8 weeks after its released and we have feedback. The Software status page lets us do a quality assessment asynchronously. If we found a major bug, we could retroactively change our recommendations. In reality we are just slow to recommend a new version.
We don’t. We see the number of upgrades as evidence of demand. We monitor bug reports and forum requests very carefully. After that we review changes to the software status page.
We are open… its why we started the software status page because of the very same feedback.
Difficult to do… warnings go away after software quality has improved, but changing the software will worsen quality. It would also slow development. We instead invest in good “rollback” solutions, release notes and the software status page.
We have finite resources and have previously had lots of negative feedback on warnings being annoying.
If we provide the software status page on the update page and perhaps a link to the release notes, would this be sufficient? We don’t want static information in the UI.
I would consider that the “Conservative” view. The fact that we don’t yet recommend it is evidence that we are also pretty conservative. Next week, we will review that Status page and adjust. By that time, there will be about 20,000 system weeks of runtime and we’ll have a pretty good idea of quality relative to Dragonfish.
We also have a very solid QA process… but it doesn’t account for creative App sets ups and the enormous range of hardware choices. Only systems testing by the Community catches this.
2 Likes
What an unbelievable response:
- The dropdown could have an info tooltip that explains what “Mission-critical”, “Conservative”, “General”, “Early Adopter” and “Tester” mean.
- Asking if anyone else has done this is a deflection. iX can write OpenZFS enhancements, and can create a great UI to docker, but they are suggesting that they can only code a dropdown and a query to match the value of this dropdown to a tag on a release if someone else has demonstrated it is possible first?
- Yes - of course everyone would prefer that every user upgrading has read the release notes first. But if you are non-technical, and non-skeptical, and have upgraded successfully umpteen times in the past without bothering to read the release notes every time and have grown to trust TrueNAS upgrades as being trouble-free, then if you are not aware that this upgrade has significantly greater risk than previous ones (because the announcements do not say anything about this upgrade being different), it is I think understandable that they may go ahead with the upgrade without reading the Release Notes and then get burned. And even more so when iX enthusiastically encourages you to upgrade despite a single and IMO somewhat obscure web page that states the software is only suitable for testing and not for production use even by Early Adopters (much less non-technical users who won’t know how to fix things that break and would almost certainly classify themselves as “Cautious” if asked).
I may be wrong about this, but based on the ongoing rah-rah encouragement to upgrade to a version that they state themselves to be suitable only for “testing” and the ongoing dismissal of the risks and apparent disregard for the risk of broken apps, definitely gives the appearance is that iX just want to boost their upgrade numbers without caring about (non-technical) users getting their systems partially-broken by the upgrade.
Rubbish!!! In each and every announcement - blog, T3 podcast, forum posts, you can state what your current view of the quality is and say e.g. “we would like you to upgrade but please be aware that as of today we think our software is only suitable for Testers and not suitable for Early Adopters, General, Cautious or Mission-Critical users.” But you choose instead to continue to encourage everyone to upgrade even though you know full well that the software is not yet stable enbough for non-technical users to upgrade to and that their systems may end-up partially broken.
Rubbish!! This is completely back to front. Demand is driven by you enthusiastically encouraging all users to upgrade despite knowing that the software is only suitable for “Testers”.
Rubbish!!! You have stated here that you can improve the migration process without needing to update the TrueNAS code by changing the individual app migration scripts downloaded during the migration. A pre-upgrade check that does a trial migration and gives warnings only when some apps don’t successfully migrate (failed iX app migration, TrueCharts Apps, users’ bespoke apps) would not be at all annoying - if all is good, a user doesn’t get a warning, and if they get a warning they will be able to choose to abort the upgrade for the moment or to continue knowing they will have fixes to do afterwards. You would also get feedback on broken app migrations BEFORE users end up with broken apps rather than only after that happens.
No - it is a start, but you need to stop enthusiastically encouraging all users to upgrade when you know full well that the software is not yet suitable for anyone other than “Testers” and you need to start being up-front and explicit in all EE upgrade-related communications about who the upgrade is suitable for and the need to review the Release Notes and do the pre-requisite preparatory actions.
Rubbish!!! iX is quite literally stating that currently this version is suitable only for “Testers”. That doesn’t mean that other users can’t make an informed decision about whether to upgrade their systems anyway, and the community has a reasonable number of technically-competent users who would be prepared to do this. And indeed, some of these users are the ones who installed the RCs and gave feedback.
However, in retrospect, whilst I still believe that in general my statement above is still the case, but for this release whose update is significantly more complex then providing that you give appropriate warnings I think that once you have had all the feedback you can from RCs you do probably need to produce a .0 version to get more of the technical users to upgrade and give you further feedback.
And will this review only take into account the stability of the O/S or will it take into account all the users who reported unexpectedly broken apps (regardless of whether they are iX, TrueCharts or bespoke apps)?
I fully believe this statement to be true - in both respects.
Your QA cannot possibly account for every combination of hardware. And even though Scale → Scale upgrades start from having a system that is already working on specific hardware, things can still break unpredictably (e.g. in Linux e.g. SAS9300-8i Detected in BIOS, but Disks Not Showing in TrueNAS GUI 4).
Rubbish!! You asked for my suggestions, but this response shows that you are NOT listening.
- The Software Status page is only of use if it is widely publicised.
- Ignoring what this page actually says in favour of rah-rah marketing in all other communications simply drowns out what this page says.
1 Like
Not sure how Proxmox is a replacement for TrueCharts. But the “good” news is that Proxmox with TrueNAS may be a “good” (i.e. big) learning curve.
Yes - of course I realise that the underlying apps are all 3rd party, and I am referring to the support i.e. TrueNAS (1st party) support the TrueNAS Chart (and now Docker) catalogue apps, but (understandably) do not support the (3rd party) TrueCharts catalogue apps.
And IME generally speaking 1st party support (i.e. end-to-end support by a single vendor) is often better than 3rd party support (split between two or more vendors).
Yes - that was not a good moment - however if I recall correctly users didn’t suddenly find themselves with apps that were broken - it was just the upgrade to the next version which didn’t work.
Also I have no idea why the refactor was needed, and whether breaking the upgrade process to achieve it was necessary either, but perhaps it was unavoidable.
TrueCharts have explained their rationale i.e. preventing new installs. Certainly in the absence of a public explanation at the time it gave the impression that they were just throwing their toys out of the pram, but perhaps they did explain it on Discord and I didn’t see it.
The first most of us knew about this was when we got an alert from our TrueNAS systems that there was an error updating the catalogue - and we then had to go and try to work out what was broken on our systems and why we were getting this error, eventually discovering on the forums why.
But whilst we may not agree with TrueCharts’ decision, since the first rule when you find yourself in a hole is to stop digging, there is a reasonable rationale for this. With the benefit of time for reflection, on the whole I agree with this decision to stop further installs, but (again with the benefit of hindsight) I would have personally them to have replaced the catalogue with an empty one in order to avoid these error messages being given to users.
Yes - as a long term decision, I am personally 100% sure that the switch to Docker is a great long-term decision and a much better overall solution, and also 100% confident that the TrueNAS Docker solution is already a solid development and will only get better over time.
What I am critical of are five things related to the upgrade / migration process:
- The decision to change technologies as a sudden-death switchover when parallel running of K8s and Docker is technically possible, and if there was parallel running then migration could be triggered by the user at a time of their choosing.
- The bad-faith dropping of 3rd party Helm catalogues after organisations like TrueCharts had invested time and effort in creating them at the request and for the benefit of TrueNAS.
- The lack of safety considerations when designing the upgrade / migration process - no pre-upgrade checks to ensure that everything will still be working afterwards - which results in partially broken systems after upgrades.
- The paucity of warnings to non-technical users warning them that their apps may not be working after the upgrade.
- The bad-faith marketing-biased announcement communications (which still continue - see yesterdays TTT youtube / podcast) which encourage everyone to upgrade to 24.10.0 when their Software Status page states unambiguously that this version is suitable only for Testing and is not suitable for production even for “Early Adopters”. When combined with the previous points this is IMO a recipe for many users having broken apps after the upgrade.