What I suggest be addressed as a serious fix for next release: DO NOT SUSPEND NODE, IF IT FAILS 1 OUT OF 2 TOTAL AUDITS. This is bad coding. Please address in next release!
Sure, but it is 1 out of 2. The satellite was fast to judge. The node was started days ago and it failed this and only this audit from all satellites. It does not make any sense. The node did not lose connectivity unless on 1 reboot. Not my problem the satellite could not connect to it ONCE without even retrying. Also 1 out of 2 - bad math STORJ. Node says this is 48.72 %. Give me a break!
Negative. You will still get suspended and you will still get that information a few hours later than you might expect. The storage node dashboard is not showing live data. It requests the data from the satellite with a high interval. That high interval is the reason why you might see 100% → 60% in just a second.
No. 29 pieces are required in order to have a valid audit result. If the satellite is unable to connect to the storage nodes we will ignore the audit result and assume the connection problem is on our end.
Do you mean the storage node dashboard API? I am not sure. We can try that out on Monday if you like.
How should the satellite garantee durability? Should we send the first 1000 files to /dev/null and just ignore any audit errors we might get back?
Your screenshot is telling a different story. If the satellite is unable to connect to you that would impact your online score. The satellite was able to reach you but you returned no data within 5 minutes (3 times in a row) or an error message.
Server.adress in config is Used only storj service port that it listening. That it is by default same as contact.external-address.
There is usualy lot of errors on node setup, when you have more that 1 node.
It will help to prevent it.
And there are both server and contact addresses listed in the go source code. The “server address” listed in config.yaml is the localhost. While the docker run command specifies the node’s network accessible address. So, these two configuration parameters are definitely not the same.
I see that the changelog seems like it’s in an “Info” function.
So, I’m really confused as to what this specific change means to a long running node with potentially old and/or deprecated elements listed in the config.yaml … and if there is anything that needs to be added or changed in order to have that node continue running without suddenly and unexpectedly losing reputation or becoming disqualified.
It’s possible that the coding change requires zero changes. However, that’s very unclear.
In this config there is 2 lines And if you use docker these stay commented out anyways.
You Have # server address of the api gateway and frontend app #console.address:
Then you have #contact.external-address:
There not even the same and dont have the same meanings. Which is also confusing do we have to go back and change every start command?
I was always under the impression that the config.yaml contained mostly local configuration items, while the docker run commandline options set the WAN needed configuration items used by the satellites.
However, the words contact or external do not appear in any of my node’s configuration files or docker configuration for my node.
If I set an address option via my docker run command via -e ADDRESS="WAN.IP:PORT", is that address the contact.external-address referred to in this coding change?
