We add to all blogs the software status page. Its in the docs and the forums.
Future UI requests should go in the Feature Request channel… that’s where we collect requirements and count the interest level. We are not opposed and have our own ideas.
Yet, I am looking right at the post in the truenas sub on reddit from 2 months ago from kmoore, and, nowhere does it link to said software status page. All I am saying is this encourages existing users to update immediately. It’s not hard to grasp I don’t think.
This announcement was better than previous ones, at least the experimental feature was specifically pointed out.
Are you not happy with this review and future action?
In short, no, that’s not what I’m talking about at all. I see that you are changing the course short term based on strong negative feedback on decision that you took into the current release. I don’t see any ”review” or self-reflection in what made you end up there in the first place, nor any plans to dig any deeper and be prepared to take steps to learn from it, adjust and improve for future major releases.
We are 2 threads and approaching 150 posts on this now, and you just linked all the way back to the opening post. It’s a little ironic given the entire discussion about actually listening and parsing over deflecting and rationalising. My advise now - and sorry if I sound patronising - would be to stop trying to defend your position on the forums and rather go back and take a deep look at this and other similar recent threads and then come back with your thoughts and conclusions, in an aggregated and forward looking manner, clearly explaining your position and via that also demonstrating that you have taken stock of what some of your most vocal community users are trying to tell you.
2 Likes
I wholeheartedly agree that users should read the release notes on major upgrades to better understand if changes will nuke prior work.
With that said, if I may make a suggestion:
How hard would it be to look through a system config as part of the update process and bring up a window wherever a change will nuke a service / whatever that the user has enabled?
Something along the lines of: “hey, I see you’re running AFP and we’ve removed that from the SCALE version you’re upgrading to. Are you sure you can live without AFP?”
Ditto VMs, apps that are known to blow up, etc.
I have no doubt that this sort of hand holding is frustrating for a programmer but at the same time it does hopefully convince those that would be affected to get their affairs into order before upgrading and getting frustrated.
2 Likes
We are always learning and fixing.
Its Ok to judge us on our future behaviour after we do it, but judging us before we do anything you don’t like is a bit unreasonable.
Lets focus on specific needs and actions… then we have a common language.
What do you need from your next NAS that is not already available?
Quite hard…
By definition the update process is running on the older software which does not know what will happen to it in the future.
So, this could only be done in TrueCommand or some form of management system. Only some users don’t use TrueCommand so we haven’t opted to invest in that approach.
That’s a good point. It would require the updater package to have a list of changes / flags and a program that goes over the config file with a fine toothed comb. If a user skips multiple system revisions, that may be a very long list and difficult to code.
That said, I wonder if such a tailored approach is too time intensive I wonder if the updater instead can have some generic warnings. Ie build in the ability for the update process to display known issues with apps, VMs, etc.
Especially if the issues are stacking like Apps moving from k3 to docker AND VMs going to be broken, etc.
Making it easy to find known issues is a goal…
If you can provide an example of a company that does a great job of automating this type of issue/warning in a complex environment, I’d love to review how they did it.
AI might be the solution??
[Engineering hat on]
It’s not very hard. You could solve it in several ways. For example by inserting a step in the update process where, prio to starting an actual upgrade, a pre-upgrade software component that was created alongside that release is downloaded and run locally. This component will be able to inspect the current system and its software and hardware and provide guidance back to the user. E.g. if you would have had this in place in 24.10, the 25.04 pre-upgrade script would be downloaded and run - it would notice that the user comes from 24.10 and runs VMs, and knowing it’s about to blow them away, could provide that guidance. It can also check that you come from a version that is supported as an upgrade path etc etc. There will be other examples in the future where you can apply it similarly.
The only slightly tricky bit about this would be to do this in a fully secure way and to design the callback APIs to drive user interaction etc.
2 Likes
I’m not talking about specific NAS features, I’m talking about your product management process and philosophy, the clarity of your product vision and roadmap, your approach to breaking changes, regression and backwards compatibility, your support cycles, your prioritisation process, your documentation and communication strategy, your interactions on social media… But we speak completely different language. Best draw a line here.
3 Likes
This is precisely what I had in mind -
Where it might get tricky though is if a user skips multiple iterations and makes a jump from let’s say 23.4 to 25.4 and thus multiple issues start stacking up, not just the stuff from 23 → 24 but also the stuff from 24 → 25. A lot of plumbing got re-arranged in the last three years.
However, even a simple window warning about the most significant changes as one does a 6 month update cadence cycle might go a long way re: averting serious problems.
For example, I had the expectation that my CORE iocage SSL scripts would survive the transition to SCALE as I was under the impression that iocage was contents allegedly getting preserved? Instead, iocage was largely a barren wasteland with lots of deletions. I thankfully had some of the recipes backed up on my Mac.
At the same time, it is super valuable to always have your recipes backed up re: how to get something to work, especially when the process to get it there took hours or days to accomplish. I still remember being so grateful for @yorick’s guide re: how to install windows in a VM on TrueNAS as that was an absolute indecipherable bear for me.
1 Like
If you want to become an Enterprise customer, please contact our sales team and we can have that discussion. We have some great products and make commitments that can go to 10 years. None of our Enterprise customers have the issues being discussed.
If you want a free Community Edition, we have a different method of engaging. We are not selling a product, we are collaborating.
Please describe the use-case you have and we can have a real discussion.
There are two issues with this entire approach:
-
When you post about the “great new TrueNAS version on social media” you don’t explicitly state “this is for early adopters” - instead you encourage everyone to update and then later on you crow about how this new release has had more upgrades than ever before. This creates the impression that it is free from risk, and that it is ready for general adoption. And in these social media posts do you refer people to the Software Status page or give any other warnings about how apps or VMs might not work afterwards? Because otherwise you are simply encouraging naive users to stumble blindly into being early adopters when they are really non-technical Conservative users.
-
Your definition of “Conservative Users” are people who have take a decision to be conservative - and thus by inference people who have enough technical knowledge to know about such classifications and to classify themselves as such. I would argue that this is entirely back to front. The default you should work to is that users are Conservative unless they have explicitly understood the additional risks of being e.g. an early adopter, and have decided that they have the skills to fix any early adopter experiences.
When you say “not provide technical advice to Conservative users” no one is suggesting that you need to get into giving tailored advice to the specific circumstances of a specific conservative user. It is perfectly normal for companies to give generic warnings in documentation and in pop-up boxes to prevent users from doing something they might regret. Indeed TrueNAS does this in hundreds of places by making users click a checkbox before they do something they might regret.
We are suggesting that iX has a more caring attitude towards less experienced, less informed users and be 1) less bullish about suggesting that they upgrade and 2) give them appropriate warnings if they are going to do an upgrade that would be risky for them.
I am arguing that iX has a responsibility to give reasonable warnings - visibly and not on an obscure web page that they may never have heard of - to all users (even those not following these forums) if an upgrade might end up breaking their system.
If you believe that the approach of:
- not warning users; and instead
- encouraging them to upgrade because they trust you;
- only for them to find that it breaks their system
is essential for iX “to function as a business”, then you went to a different business school than I did!
And that, my friend, is why it is beneficial to consult with experienced, knowledgeable community members when deciding how to approach a new technology, who might be able to give you 20/20 foresight that you were biting off more than you could chew.
If your choice of Incus implementation was:
- Only LXCs
- Only virtualization
- Both
then if you had asked I think you would have been advised by many of us to do just LXCs in the first version - because whilst it wasn’t obvious to iX, it would have been obvious to some of us.
In other words, don’t rely on hindsight to say you didn’t have better input, but instead go out and seek it.
Only works for those people who have the time to follow these - those users who installed TrueNAS as an appliance to support their business or busy home lives and who don’t follow your blogs simply won’t learn about it. Perhaps all they ever see are the social media rah-rah “upgrade now” posts.
Except that history suggests otherwise as this is not the first or second technology adoption decision that has been painful for users, and this thread is full of excuses as to why you can’t prevent them.
I would summarise what myself and others are saying as:
-
history is a series of technical adoption decisions that have been painful for significant parts of your user base; and
-
these concerns have been pointed out to iX on previous such occasions;
-
and yet here we are with another “with the benefit of hindsight” statement demonstrating that that iX does not listen, doesn’t do deep reflection, doesn’t admit mistakes but instead defends its actions with excuses.
The review and future action is a recovery action - and this is good in terms of moving forwards after a mistake. But what we would (obviously) prefer to happen is NOT to get into this situation in the first place i.e. to have foresight rather than hindsight.
The experienced members of this community could help you have foresight if you were prepared to let us do so.
This is factually incorrect. I can immediately think of two ways to achieve this:
-
You can have generic code in the current release that can (securely) download and run a script associated with a specific release that can do this analysis.
-
You can have generic code in the current release that can download a json/xml/yaml file for a specific release that defines which services need user actions to migrate, and then you can check whether those services are enabled on the current instance.
All that is needed is for iX to a) want to warn users; and b) to have some foresight, neither of which currently appear to be the case.
I don’t see how Artificial Idiocy (with its penchant for hallucinations) can be a solution. These forums and Reddit both contain people asking for help after they consulted ChatGPT for solutions.
Indeed, on the only occasion I tried using the TrueNAS documentation AI (as a test), it hallucinated and gave me a factually incorrect answer. Fortunately I was knowledgeable enough to recognise that it was incorrect.
Great to hear that we are collaborating. But can you explain exactly what this collaboration entails? Because the gist of this discussion suggests that iX’s definition of “collaboration” might not be the same as the community’s.
4 Likes
While I applaud the courage to say “we’re going to revert this decision because we made a mistake”, that courage wouldn’t have been needed with better management decisions beforehand.
There shouldn’t have been a plan A and plan B, there should’ve been a single plan that meant not removing much-used features (VMs) before the new system was ready for primetime.
The fact of the mater is: this was crossly mismanaged
Mistakes happen, by any employee including managing staff. But, as many people point out, these kind of management-level decisions happen remarkably often with iX. So often that people are rightfully asking if the company is actually learning from mistakes.
And learning could mean a lot, it could mean either more training, changing processes or removing repeat-offending managers.
But many of us here, have the feeling that none of those learning steps are actually taken. Not previously and not now. They get the feeling iX is changing into a “coral-loop”
There is no “we’re changing X and Y to prevent this in the future” accountability being taken.
Instead we do get finger pointing to users and manuals. Which is correct, in a certain way, but is not actually answering the root cause of distrust from long-term users.
Please note:
I’m not pointing the finger here at anyone specifically or trying to attack anyone at all, this is just a rehash from the complaints I see here and elsewhere. And the completely lack of actual 2 way communication between the distrustful and iX.
8 Likes
I’m stable branch, am I wrong to be annoyed if the release note contradicts that? I was OK with incus being experimental. But as I’m not in the beta branch, I assumed it would be feature equivalent. But you removed GUI management of VM drives. Although on the assumption nothing else breaks I am mostly happy for the upgrade, as it fixed some things you didn’t expose settings to fix like software vram size.
What others have called deflection I’d call gaslighting. Users have predictable communication needs and tendencies to click upgrade buttons on the upgrade button clicking screen. To pretend their needs are something else so consistently is dishonest.
I tested TN Scale 25.04.02 I believe, it was awesome in regards to Portainer + Docker containers, I was happy with it. Then I wanted to install OpenWRT or OPNSense - and remembered, that TrueNAS Scale used to have nice virtualization last time I tried (I think 24.xx or something)… and was dumb-founded by the VM feature being marked as experimental…
So I removed TN Scale from my server (it was installed bare-metal), installed Proxmox, went through the pain of writing a Terraform script for set up of a single-node Kubernetes cluster with Talos (it might have been smarter to go with FlatCar or something, but I didn’t think of it early enough) and can now install OpenWRT/OPNSense without any hassle or problems or experimental features, that don’t really add anything other than being “different” (i.e. not libvirt-based).
Way to lose a user sadly… not saying I might’ve become a paying customer - not sure, maybe not… but I am not installing something like a router onto a server with the VM feature is experimental.
For virtualization, it is experimental. We are fixing that in 25.04.2
The software status page is where to get information about what to use. We do not recommend ignoring it.
Sorry to hear but 24.04.2.2 would have been our recommendation.
25.04.2 will also get it.
1 Like
One of the reasons it’s obscure is that users don’t acknowledge how important it is.
The obscure page is the key to a better experience… its VERY important and is called the software status page.
Users who follow it have good experiences. Users who don’t are much more likely to have problems.
We plan to make this even more obvious in the future… but in the meantime that is the best we can do.