80% of Community users don’t need VMs.
100% of Enterprise users don’t need VMs. (we’d prefer to lower that number)
There were many other features in Fangtooth that the Community and Enterprises wanted.
We expect this approach will mean VMs will be better in Goldeye, including Enterprise.
So with is data and your project manager hat on, would you delay the release by months? My conclusion was “no”.
You keep us accountable… we give you the ammunition.
If in your terms this thread is an example of accountability, then it is a failure at that.
You have completely failed to provide transparency about your decisions, and have not provided any genuine ammunition.
And every time we attempt to explain why we believe your decisions were wrong you just deflect and refuse to accept even the possibility that the decision could have been better.
This is the absolute opposite of accountability.
If anyone is interested, here is what I think is an appropriate definition in the circumstances of a private company and a community user base: Accountability for reasonableness - Wikipedia
But personally I am not sure I can be bothered discussing this with an organisation which has its corporate fingers in its corporate ears whilst saying “wibble wibble wibble” as loudly as possible. (For those not from the UK this is an allusion to an episode of Blackadder series 4 - see "Blackadder Goes Forth" Goodbyeee (TV Episode 1989) - Rowan Atkinson as Captain Edmund Blackadder - IMDb ).
I think Morgan is attempting to create a Steve Jobs Reality Distortion Field–but he isn’t Steve Jobs.
Entirely insufficient data for anyone outside iX to make any judgement, about impact of alternative approaches on timescales.
As I have already explained, the QA and risks could actually have been lower. But even if it wasn’t…
As already explained, a 25.04 deadline was arbitrary. a 25.05 or 25.06 delivery might have been possible and less risky, and would definitely have avoided all the risks for those people who actually tripped over them and screwed up their production systems.
Your argument here is effectively that the risks to users production services have no weight and don’t matter, and instead the risk of missing an arbitrary deadline is the driving force on decision making. This absolutely stinks.
We’ve accepted that when we announced that 25.04.2 will support both.
However, that decision was easier after the engineers had 6 months of experience working with the new stack. Hindsight makes all decisions a bit easier.
Another deflection and refusal to be accountable for a potentially bad decision.
Nope - had iX listened to feedback on EE it would have been foresight not hindsight. So another deflection and refusal to be accountable.
Is it any wonder that the community has so little confidence in iX’s technology strategies around containerisations?
Is it any wonder that we don’t feel that iX actually listens?
The first part is true - where you are it is a Saturday afternoon. The rest is exaggeration at best.
This discussion feels to me to be a bit like a chat with the 1966 Chatbot Eliza - Eliza was “listening” and “responding” too.
You are not really listening because you are deflecting, ignoring huge swathes of debate, being selective about which points you respond to, making statements which are provably factually inaccurate to a greater extent, ignoring history and not providing any real answers to the main points being raised.
That’s not my argument.
We agreed to label the Incus software as experimental and recommend against production users migrating their VMs.
So, my argument is that users doing major updates without reading release notes or the software status page do so at their own risk.
We strongly discourage anyone suggesting that major updates are risk-free… we have not made that claim and have no intentions to do so. We host these forums so that users can post experiences and questions and minimize risks and resolve issues.
We can do better with with advising about updates in the UI… looking forward to any feature requests along those lines.
To paraphrase what you just said…
Your argument is that iX doesn’t need to take any responsibility for any users who upgrade and then find their systems are broken to some extent because they should have read:
The release notes which are linked to on the upgrade page but which don’t really warn bluntly about what will happen and which say absolutely nothing about the need for rebuilding O/S images with new drivers and which gives literally no warnings (the word “warning” literally doesn’t appear) about what will happen or who should avoid it.
The Software Status page which is not linked on the upgrade screen - and although it is linked to on the Release Notes page, there is nothing that really draws attention to it or warns that if you ignore it and upgrade prematurely you could have your production functionality broken.
and having read those two pages (and nothing else - lots of users are NOT regularly reading these forums) they are expected to understand that their system is going to break and not upgrade.
And none of this is iX’s fault even though the community has been asking for months for iX to provide more explicit warnings and take more responsibility for stopping users from stupidly breaking their systems.
Yes - blaming the customer is always a great look for a company. Well done!
Yes, I do that because I respond to areas where I disagree with an assertion. I’d rather the forums don’t have wrong information about our processes.
If I don’t have reason to disagree with an assertion, I may not respond. I may be listening, but I’m looking to see what others think as well.
Please don’t take it personally.
Oh - I am not taking it personally, I assure you.
I do not think that you are treating me in any special way - I believe that you would treat all community members this way.
Not quite… we share responsibility. That’s why we’re releasing 25.04.2
I’m just not giving users a free pass to assume updates will work flawlessly.
In future, we’d like to improve that, but in the meantime users needs to read the docs provided.
LOL!!! I can’t believe you took the time to create those (the previous animated GIF and this later pic) - and I cannot believe how accurately you have depicted me. LOLOLOLOLOLOL!!!
Admire Truenas CE for trying out experimental features like Incus and making dramatic changes like moving apps to Docker, which I think makes it one of the more aggressive Linux OSs and is consistent with its cadence of 2 major releases a year. Maybe some would say Truenas is not aggressive in its development because it’s not cutting edge like Arch Linux but it certainly isn’t rock solid stable like Debian which is a rolling release with a major release every 2 years. In the middle is Fedora which like Truenas has 2 major releases each year but is a rolling release with sometimes hundreds of updates a week. If IX had the resources to do a rolling release, perhaps the aggressive development of Truenas CE would be smoother process with less stress on its users. Of course, some would say I’m comparing apples to oranges because Truenas CE is a NAS OS not like those other Linux distros. Truenas, as a NAS OS, is compared everyday to other Linux distros on DistroWatch.com and probably should be more stable than the ordinary Linux OS simply because it is a NAS. To wrap up this rambling, I think Truenas CE users just have to accept that it is an OS under aggressive development which is oriented more toward home labs run by users with professional IT experience. Other more casual users who want to spend most of their time doing production work rather than tinkering with their Truenas will be seriously challenged.
That’s our view of the Conservative user. They will update once every 1-3 years.
If they follow advice, it will be the last update of each major version and they may skip a version occasionally. If they hit a relevant bug, then they have to update.
Our Mission-critical Enterprise users will often go througn a 5 year lifecycle without an update. Others will update annually as needed.
Everyone gets to choose their own path…
Correction, you are not a customer. Customers are people who pay for a product or service. You are just a free user.
And for the question about accountability. iX are accountable to their customers. They are not accountable to free users.
Since you ask - I do, I think it’s more complex to support multiple methods in parallell to achieve similar things. That’s not hypothetical, I only need to look at Proxmox to see the confusion it can create in the user base, so I understand the hesitation to do it.
In 25.04.2 iX will be offering four different ways of running third party code, Docker apps, oldstyle-KVM VMs, new incus KVM VMs and finally incus containers. Beyond that I wouldn’t be surprised if some users go for the unofficial fifth option, and run their own apps stack in jailmaker. Fortunately, iX didn’t decide to offer both Kubernetes and Docker apps subsystems at the same time, now that would have been a disaster.
In this situation offering both KVM integrations may still be the best choice, I guess we’re about to find out.
When you continually say “we” or “the community” please remember that you do not speak for anyone but yourself. Some probably agree, but not all. You also portray things as rather black and white with an authoritative and accusatory tone. Reality is often not quite as clear cut, and I ask you to, pardon the pun, tone that down a bit for the sake of the discussion.
Your point about 4-way combinations of containers is a very good one.
I don’t think that libvirt / incus and kubernetes / docker are the same in regard to additional complexity. But the decision making process was essentially the same - don’t even consider parallel running.
libvirt and incus both use KVM and can coexist easily - and the additional QA needed to double check that they can co-exist is (at least in part) matched by not having to do quite so much QA on the Incus side because users with production VMs who move to Fangtooth to get LXCs wouldn’t need Incus virtualisation to be production quality.
That said, there are 16 possible combinations of Docker, libvirt VMs, Incus VMs, Incus LXCs (from running none through to running all) cf. 8 ways if libvirt is excluded - so when it comes to checking that they don’t clash, that does double that type of QA - but I would think that each of those QA tests is small by comparison with the QA of the new base Incus functionality and the new Containers management functionality.
So the question then becomes one of weighing up the benefits with the additional QA, and not a black and white decision to avoid parallel running because any extra complexity is a bad thing.
I suspect that Kubernetes and Docker couldn’t both exist natively - and so perhaps Kubernetes would need to be made to run under Docker and this would need significant extra development and QA effort cf. a technology swap out. But on the other hand, the number of Kubernetes app users was maybe 10x-100x as many as VM users, so the benefits would have been greater too.
As I have said previously, there has been way too little information shared for any community member to make a valid risk and effort assessment about either of these two situations, but there is no indication that parallel running was even considered in either case. And as discussed, the alternative way of preventing users upgrades screwing up their production system - blunt in your face warnings - was not considered either.
I know I don’t speak for the entire community and as far as I can see I haven’t suggested that I do even once. (I asked whether the community would agree, but that is not the same as stating that they do. Another member did make a statement attributed to the entire community, but that was not me.) As an aside, my overall philosophy is that others are as entitled to their own opinions as I am entitled to mine, even if they are the opposite of my own - a variety of views is a positive thing IMO.
Yes - as I have already said, I dislike the tone that this discussion has descended to. However my tone (which as I have said I dislike using) is a response to an iX attitude of ever admitting to a mistake, completely ignoring points that they feel might lead to them having to admit to a mistake, and making statements about their approach which do not match up to written evidence elsewhere. And when answers are withheld, you can only make assumptions about what they are and why they are withheld and then you end up sounding black/white and accusatory.
As you say, real life is never completely black & white and (unlike some) as and when I am presented with more information I always try to listen and then revisit the point and see if I was wrong - and if it turns out I was wrong I am almost always willing to admit that (rather than be defensive) and thus learn from it.
If iX demonstrated more willingness to be open, to listen and reflect and learn, and thus deliver a better experience to users based on community feedback, then community members like me wouldn’t (to refer back to @Stux) feel like they had to flog a dead horse to get a point listened to - and then discussions would indeed be more empathetic and multi-faceted.
However, since I have taken @Stux’s humorous comment on board, and I have already made my points bluntly, I am not going to continue repeating them - at least not until the next time the same thing happens again.
Yes - I should have said “Blaming the Users is not a great look for a company”.
That is not what iX said earlier in this thread - they said they want to be accountable to the community (which I think is in terms of Accountability for Reasonableness).
But from a pure capitalistic business perspective, iX are accountable only to their shareholders and to the explicit wording of the written contracts they have with their paying customers. And this is a whole different type of accountability - financial accountability.
