I’ve made no secret on Reddit and other discussions of the fact that we are exploring the alternative option of adding native Docker + Compose support. K3s has been a huge disappointment in terms of bloat, stability and complexity for our purposes. It’s been the number #1 source of issues on SCALE to date. The reason people still have to speculate is because we haven’t announced if/when that might happen. Because we haven’t determined that ourselves yet… Once that is decided, nothing will be done in “secret”, just like the Netdata implementation wasn’t. This is an open source project, everything we do is visible to anybody who wants to bother spending time looking. Granted we sometimes screw up Jira visibility, but on the Github side, everything is always open..
Anyway, you really can’t get a more senior iX response than this. While we can always communicate better (and strive to do so), this will be through conversations and release notes whenever possible. We can’t sit around and argue with a brick wall all day like this thread has become. We have to get some work done in the meantime. Considering that we give this product away for free to the world, I think we’re doing a pretty decent job of trying to make forward progress, while still engaging with community feedback. The fact that we are actively looking at how to re-enable longer-term lossy stats based on that community feedback is evidence enough. If that doesn’t satisfy you, then you will have to remain unsatisfied. Meanwhile I’m going to move onto other topics that don’t beat the same dead horse over and over.
Yet again you are either failing to understand my concerns or being deliberately disingenuous.
As I have pointed out already several times, whilst some people may have an issue with a switch to Netdata I am not one of them and what was secret was NOT the overall Netdata implementation, but rather the reduction in reporting data retention from 6 months to 7 days. So please can ixSystems personnel stop mischaracterising both what you did and didn’t say/do and also the concerns I am raising.
Being open and transparent is NOT (IMO at least) just about doing it in a public Github repository - it is about summarising into plain language (rather than Python code - some of us can read code, but many can’t) the changes you are making and publicising them as part of the Change Log/Release Notes which are what people actually read when planning a version upgrade or doing Beta testing. It is IMO utterly ridiculous to expect users to review each and every PR or commit on a Github repo (or possibly several separate Github repos) in order to determine what is changing.
The fact that you either do not understand these distinctions or are deliberately ignoring and mis-characterising them worries me a lot - because in my mind it suggests that this choice to implement what your Enterprise customers want without considering the impact on other user groups (like small/free users) starts to look less like a mistake/blip and more like a change of corporate policy.
I think that you also know from what I have said elsewhere that I am in general terms both very grateful for having the free use of TrueNAS and positive overall about the software and ixSystems, and I always try to recognise this whenever I can by making positive comments. But that does not mean that I am going to (or even should) turn a blind eye to what I consider to be a serious and potentially long-term issue for small/free users.
Turning now to a potential switch from Kubernetes to Docker (and the past change to Netdata or from Xenforo to Discourse), other users may (understandably) not want the hassle of managing the consequences of these sorts of changes and don’t see the necessity of ixSystems making them. My own views differ - I have been in IT for decades, working for equipment manufacturers, outsourcers and large enterprise IT departments and managing large scale projects (including massive storage projects), and so I do understand that these sorts of changes are made for good reasons, and that whilst they do create workload for users we just have to go with them.
But just so we are clear - though I cannot believe that I am having to say this yet again to get my point across because I thought I had been reasonably clear before - the issue is not about making these technical decisions but about how you go about implementing them. To take the future Docker example…
I find Kubernetes very complicated to understand. and having LOTS of configuration parameters that I find indistinguishable from magic - which sometimes makes getting a SCALE app working very difficult. ixSystems does a good job of documenting how to implement your Charts, but TrueCharts documentation is practically non-existent. So when there are versions in both catalogs, I tend to use the ixSystems one (examples: Plex, Unifi, Syncthing, rsyncd). At present, I have no reason to believe that a switch to Docker will not be accompanied by ixSystems producing equivalent Docker versions of your Chart apps. On the other hand, I have no idea how a change to Docker will impact the few TrueChart apps I run (though most Charts are based on Docker images in the first place, so depending on how you implement Docker this may be either a minor issue or a significant one).
I also have no idea what impact this will have on CPU or memory usage and whether it will obsolete my existing hardware. Nor do I have any idea whether there will be a transition period to allow for non-disruptive switch over from K3S to Docker or whether a version upgrade will require a migration at the same time. I appreciate that it is almost certainly too early in the development cycle and decision making for ixSystems to consdier these points, but what concerns me is whether ixSystems will consider them at all, and whether we will get long-term information to allow us to plan ahead.
So, whether the change from K3S to Docker (which I personally see as a long-term benefit) is going to be friendly or unfriendly will depend on how well ixSystems works with those users groups for whom this will have the most impact - which I think are the exact same small/free users who have been impacted by this reduction in reporting data storage from 6 months to 7 days.
And this is precisely why I find the Netdata implementation to be so worrying. If ixSystems doesn’t care about our class of users because you don’t recognise the (non-revenue) benefits that we deliver, and if a Docker implementation is done with a similar disregard for the needs of, and consultation with, us small/free users, I think that this will be a disaster for us, and you may well lose a large chunk of your base of evangelists and beta testers. Of course, if that is not a worry to you, fair enough - but if this is the case, then please say so that we can plan ahead.
All I am asking for is for them to acknowledge that they could have done better and to pledge to try not to let the same thing happen again. Is that too much to ask?
