For Storage Nodes
Slight adjustment to the order settlement check interval
We noticed, that with a past change the check interval of submitting orders was reduced to 5 minutes to prepare for the upcoming changes to the handling system. However, with the current system this caused increased load and contention on the satellite side and potential timeouts during order submission. With this release the interval has been changed back to one hour to reduce contention.
WOW… v.1.14.7
Looks like my nodes got updated to 1.14.7 as well. Seems to work just fine though, buy I am a little surprised to see that listed as a minimum version right away, since it was suggested in other topics that nodes wouldn’t get traffic if they didn’t at least run the version mentioned there.
As far as I know the docker image only just became available, which means it’ll take up to three days more until all nodes are updated by watchtower.
@stefanbenten, am I misinterpreting your comments?
This is not wrong. We intentionally set the minimum version higher now to ensure we can proceed with protocol changes more frequently.
As you might have seen by now, we also released:
As we are soon creating the next minor version (v1.15.x) and starting that rollout, having minimum and suggested match is as said intentional.
So that means existing SNO’s using watch tower will not see any traffic due to docker image not being updated until 3 days later, or am I missing something here?
That didn’t seem to be the case for me. Though that’s in contradiction to what Stefan said before. So I’m a little confused.
As mentioned before, the safe version to be one is the one listed under processes.minimum. Everything lower than this is not guaranteed to get uploads, especially when being more than 1 minor release behind that one.
We are aware of that docker nodes get the update last and take hours up to days and thus our current soft limit is (as mentioned above) one minor version lower than the current satellite version. Meaning everyone that is on v1.13.0 an higher will not have any impact with our satellite being on v1.14.7.
Also traffic in your case hopefully just means uploads, because thats the only place where the soft limit takes action on.
The point here is:
Do not mess with manual scripts/updates rather than use the provided/recommended tooling.
If you are missing bits on the existing tooling, make proposals in the corresponding subforum, so that we can improve and add them. Doing manual updates makes our overall progress much, much slower and it is in the best interest of us all to develop and release new features and/or bugfixes with a smaller turn around time.
I little bit confused with your different replies…
So, where is true?
Every node thats not within the “recommended” minimum version range (to be found on version.storj.io in the processes section), are not getting ingress data.
or
Everything lower than this is not guaranteed to get uploads, especially when being more than 1 minor release behind that one.
The first one is missing a bit 
should be:
Sorry for the bad wording, english is also hard for me as German.
As wrote just above, we currently allow being 1 minor version behind, but are planning on automating automatic increases of the given soft limit.
Thanks a lot for the clarification!
Don’t worry, I suspect that is just a lack of information on the first post
Now is clear to me, thanks again!
This cleared it up for me. I thought based on previous posts that anything below that would not get uploads. But this explained that it might not get uploads, but it still could. (I’m assuming docker nodes with watchtower get enough time to upgrade.)
Thanks for the clarification!
Language is hard, same as coding
Glad it helped!
Minimum version states 1.14.7 in https://version.storj.io/
Docker latest version I checked last night was still 1.13.3, hence my question why all of a sudden we are no longer showing minimum version no# lower than latest version and also shows others are confused as well.
That means my SN 1.13.3 (latest) is actually not the latest but docker / watch tower hasn’t pulled 1.14.7, so ingress will be stopped… 
Maybe watch tower is having an issue so I’ll kill it tonight and review further if I need to manually update.
For docker nodes you should read this part
"Storagenode":{"major":1,"minor":12,"patch":0}
For GUI you should read this part 
The reason being it is listed under processes
"storagenode":{"minimum":{"version":"1.14.7"}
Can you verify if your node has free space to get some ingress ?
So, minimum version != minimum version… 
{"Satellite":{"major":1,"minor":10,"patch":0},
"Storagenode":{"major":1,"minor":12,"patch":0},
"Uplink":{"major":1,"minor":0,"patch":0},
"Gateway":{"major":1,"minor":0,"patch":0},
"Identity":{"major":1,"minor":0,"patch":0},
"processes":{
"satellite":{"minimum":{"version":"v0.0.1","url":""},"suggested":{"version":"v0.0.1","url":""},"rollout":{"seed":"","cursor":""}},
"storagenode":{"minimum":{"version":"1.14.7","url":"https://github.com/storj/storj/releases/download/v1.14.7/storagenode_{os}_{arch}.zip"},"suggested":{"version":"1.14.7","url":"https://github.com/storj/storj/releases/download/v1.14.7/storagenode_{os}_{arch}.zip"},"rollout":{"seed":"e375e7f587ba358a95577aed38637a71e429703d7bc82e5d6f87cb78a267f83e","cursor":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"}},
"storagenode-updater":{"minimum":{"version":"1.14.7","url":"https://github.com/storj/storj/releases/download/v1.14.7/storagenode-updater_{os}_{arch}.zip"},"suggested":{"version":"1.14.7","url":"https://github.com/storj/storj/releases/download/v1.14.7/storagenode-updater_{os}_{arch}.zip"},"rollout":the minimum for both is currently 1.14.7 and the docker has been available since days now.
How is that clear now? You’re always the one saying that you can proof every behaviour from code. In code there is no “it might not get uploads”. You either get uploads according to a set of rules or you don’t. And if you are lower than the recommended minimum version, you don’t get ingress. It’s not a game of chance (unless that’s in the code), it’s a set of rules.
It explained why my nodes were briefly below the soft limit and still got traffic. I don’t have time to dig through the code right now, but I assume this is just a separate satellite side setting. So it’s not a matter of code, but a matter of policy when it is changed. What was cleared up is when they might change that. It’s usually 1 version below the soft limit but it can be changed once the automatic updates have fully rolled out and docker nodes have had enough time to update. Sounds reasonable enough to me.