Changelog v1.6.4

ill need to check if its back… there was a long long time with nearly no traffic which kinda disrupted my testing… and kinda forgot about it… also haven’t rebooted for a week and it’s usually after reboots it an issue for me… or during clean up… ill have to inspect my logs more closely

A post was split to a new topic: FATAL Unrecoverable error {“error”: “CreateFile

Is this update stuck somewhere?
My dockers still haven’t got it :expressionless: while it’s more then a week since it’s released.

the docker version is one of the last versions to get updated… also it takes a bit before watchtower updates some nodes, so that it doesn’t bring down the entire network due to an update…

so i would guess that the docker version isn’t out yet… will be during this week tho… most likely in a couple of days.

yeah it isn’t out yet… you can use this link to check
https://hub.docker.com/r/storjlabs/storagenode/tags?page=1&name=beta

Thank you SGC, i know all these conditions. And i’m very happy that experiments with new releases are performed on Windows users first :smiley: :smiley: :smiley:

But usually it takes less time to update. So wondering maybe a bug was found or something like that.

1 Like
4 Likes

why i like to be among the last to update :smiley: and why i do so manually…

2 Likes

4 posts were split to a new topic: Why is such a great discrepancies in available disk space between the three different methods?

I remember long time ago there was a strict rule, where all nodes should be updated within 72 hours after update released. If not, reputation went down or smth like that.
But now looks like there is no this rule anymore?

1 Like

They have a staggered approach these days.

I think most nodes are runding docker, which doesn’t get the updates until around a week after initial release.

I’m still waiting for update on my docker nodes for the current release.

p.s. I also know that if your running really old node software it won’t work either. But that’s many versions ago, not 72 hours old.

There is. It´s just that update to 1.6.3 was causing nodes to stop provoking fatal errors. Rollout is stopped and the issue was escalated internally I think.

while the software was in alpha and beta yes 72 hours was the case but once it went into production updates to the software became a controlled rollout to prevent bad things that may not show their face until it went into real world environment hope I got the explanation correct.

1 Like

well you still get warning emails… :smiley: tho only after you are like 1 version behind…
i still think the update schedule is a bit strict, like now you can run 1.3.3 as the oldest version… ofc since updates are coming in frequently, it makes sense to try and keep nodes on the same version almost…

but it is nice when one only has to update like once every quarter… but yeah … future thing i suppose… atleast if i keep my manual updates… might go to watchtower if i end up trusting it :smiley:

I believe that guideline is still similar, but it’s just 3 days after the rollout has finished now.

But there is some nuance, it’s not “If your node hasn’t updated three days after rollout is done, your reputation will be harmed”, but rather “if your node updates before three days after rollout is done its reputation won’t be harmed”. Beyond that 3 day limit, you may still be fine, but no promises.

I most cases you have much longer to update your node. But this rule gives storjlabs the option to update nodes to a later version fast should some change require it.

From what I can tell that reputation impact currently just means outdated nodes won’t be selected for uploads anymore. And possibly don’t get downloads either, though not entirely sure about that one. Though this may obviously change in the future. I can imagine the node would just be considered as offline at some point, which would hurt your uptime reputation.

3 days seems kinda of low to shutdown, updated and restart like 10000 nodes +
if we say 6k nodes which is very low estimate, which we divide by 24, so thats how many they would have to shutdown, updated and restart in 1 hour, so 250 and divided by 60 minutes in an hour so 4.16 nodes that would have to be rebooted

i guess if we assume three times the nodes and thus three times the time… then we end up with the same… 4.16 nodes a second for 3 days straight to update them all… i duno how many the system can do or would loose … but it does atleast in theory look is a pretty difficult task.

and then on top of that comes the whole… OPS we updated our entire network to a bad release and now every node crashed and we cannot restart any of them…

1 Like

7 days for windows nodes + 3 days for docker nodes + 3 days grace period… we’re talking about 13 days normally.

1 Like

Is there a statistic how much nodes (%) are in Windows, how much in docker?

Not really.
You can see a total number of pulls for the storagenode image: https://hub.docker.com/v2/repositories/storjlabs/storagenode/ but it useless
However, you can configure something like https://www.gasimof.com/blog/track_docker_image_pulls/ to track this stat.

The same is going for the binaries (you can take a look on number of downloads): https://api.github.com/repos/storj/storj/releases

And moreover - the docker can be run on Windows (and MacOS) too

I’m sure this will be integrated in the binaries in the future to report such things to Storj.

Is the upgrade finish on docker? Usually it take less then 2 week after the announcement? My watchtower didn’t update the node yet.