Changelog v1.14.4

[Odmin]

Somthing go wrong with version again…

[BrightSilence]

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?

[stefanbenten]

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:

Changelog v1.14.7

For Storagenodes: Small version bump to have automatic updater users match the docker release Due to an interal oversight, the docker images were bumped to v1.14.7, whereas the storagenode updater and versioncontrol still recommended v1.14.4. We pushed the updated version, but there are no functional differences on the storagenode side compared with v1.14.4. For Satellites We implemented a QoS tier for order submission against client facing requests to ensure neither of them are blocking e…

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.

[Odmin]

Now I see the fix

In my previous post, I mean that we have the newest version that “suggested”.

[Sasha]

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?

[BrightSilence]

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.

[stefanbenten]

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.

[Odmin]

@stefanbenten

@SGC we have measurements in place to encourage updating nodes. 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.
We do discourage manual updates this was, as its fundamental for our network to make progress and have a unified node base. If the spread of versions is to wide, then changes to the protocol wont work together.

The minimum version on version.storj.io is the actual minimum allowed version, everything lower than this is entirely unsupported. The second one is a soft limit to encourage updating

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.

[stefanbenten]

The first one is missing a bit

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.

should be:

Every node thats not within the “recommended” minimum version range (to be found on version.storj.io in the processes section), is not guaranteed getting ingress data.

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.

[Odmin]

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!

[BrightSilence]

@stefanbenten

Everything lower than this is not guaranteed to get uploads

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!

[stefanbenten]

Language is hard, same as coding
Glad it helped!

[Sasha]

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.

[nerdatwork]

@Sasha

Minimum version states 1.14.7 in https://version.storj.io/

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 ?

[Sasha]

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":

[kevink]

the minimum for both is currently 1.14.7 and the docker has been available since days now.

[kevink]

@BrightSilence

@stefanbenten

Everything lower than this is not guaranteed to get uploads

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.

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.

[BrightSilence]

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.

[stefanbenten]

I even gave the exact behavior in a channel. We select Everything that’s at max 1 minor version behind the satellite.
Eg. If the satellite is on v1.14.X, everything running on v1.13.X and up gets ingress.
The flag that we use for that is —overlay.node.minimum-version

I am really not sure why you keep on insisting us doing ninja tricks to make storagenodes unhappy. I tried my best to explain why this secondary soft limit exists and how a bad updater in v1.12.3 has caused the problem of not getting ingress.

Doing manual updates whenever you feel like it is simply discouraged and automatic updates are the recommended way for your node to stay healthy. If you can not accept this fact, then this is still no reason to keep blaming others.