I was hoping for some evidence of failure where was evident.
The length of 98% of your posts give a visual belief that you do know a lot about a lot of things but as previously mentioned you can refer the blog or whitepaper.
How is that even remotely connected to storagenode dependencies !
Storj takes pride in providing nine 9s durability so I am 100% sure they would like to get to the bottom of this claim. I have purposefully made the text bold in above quote to point out the base of this claim.
Again how’s that related to storagenode dependencies.
Could you please elaborate that point in short ?
Yes that’s summarizing first post. Thank you.
I understand where this originates from but whenever it’s possible devs do respond to genuine queries and bugs. You have to also understand nobody runs a business just to run it to the ground for no reason. So your point is absolutely correct there needs to be verification of stable and working releases. I have witnessed when a bug was affecting a lot of SNOs and devs worked over time to release a patch in matter of hours which fixed it (during alpha days).
Every staff that has ever interacted with SNOs have asked again and again to point out any bugs/issues that you encounter. Hence I would like to ask you to point out any chaotic experience you have encountered.
I remember Stefan mentioning about getting satellites on track with proper decentralization so that is on the roadmap too but other priorities take precedence.
After reading 8 points I think you have a beautiful mind. You do indeed have wealth of knowledge but sometimes you club valid points with theories that don’t necessarily relate to point/topic under discussion.
DQ for tool old version seems a bit too fast though. Probably would be better if the satellite just did not accept connections from a node that’s too old, so the node would eventually be suspended/DQ for downtime, but, assuming the node did not have downtime before getting too old, it would take some time and would still allow the operator to update.
I think instead of disqualifying nodes, the network should simply stop nodes with older versions from connecting with the network completely. IIRC node does check for valid version every 5 mins.
A log message should reflect the same as to help SNO understand the issue.
Error: Outdated version, node’s version is older than minimum allowed version
Except older SNOs (older in terms of node’s age) most SNOs are in the mindset of setup and forget. We have to understand they come from “mining” background. There will be SNOs that have faulty watchtower setup or use older watchtower command. A bug in storagenode-updater that won’t automatically update the node so to be fair to them, denying connectivity to the network would be appropriate action than DQ.
I think you think to far into something, storj needs a control and a way to control a bunch of people not maintaining there nodes. This is why Auto updates is prudent for keeping the service strong not because storj hates everyone. Your node is the only thing that can get you DQed not your docker version or your updates for your OS.
That’s not a reason for not sending emails. You could say the same about the forum and the GUI dashboard, not everyone looks at them regularly. So why not using all available channels of communication? Send an email, display it in the dashboard AND have a sticky topic here.
I think that it would still reach more people than a post on the forum even if some people didn’t put their real email.
Also it’s kind of a sensitive subject since it involves a possible disqualification and from my point of view it doesn’t hurt to send an email to all SNOs.
Hey @Pentium100 this is actually on purpose! We do NOT want the entire network to update all at the same time which is why we have the random interval delay between 12 and 72 hours. If all nodes updated as soon as we published a new release we would see adverse side effects across all of the parts of the network.