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.
Would there be any issues with just using a script that checks on a weekly basis if docker pull gets a newer version and then just relaunches each container?
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.
I believe the exact quote was 3 minor versions behind.
Version numbers have the format v[major].[minor].[patch]
So v1.14.1, v1.14.4 and v1.14.7 are all the same minor version v1.14.x.
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.
The email was sent to the SNOs with outdated software.
However, if their email addresses are fake - then they should monitor the forum.
I do not see any other option to reach them out…
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.
This already done as far as I remember.
We even have the information in each such email:
We’re contacting you to let you know you need to update your Storage Node’s software. It’s currently out of date, and we don’t want your reputation impacted if you were unaware of the situation.
was evident.