Yeah, this doesn’t normally happen, but there was a big in 1.67.1, so they started rolling out 1.67.3, but started the process over. As a result if you removed the container or restarted it, the updater would see this node isn’t ready to receive 1.67.3 yet and downgraded it to 1.66.1, which was the last fully released version.
Can someone explain, how this cursor works? Is it similar to umask in linux? But the NodeIDs are not hexadecimal and also they all start with 1…, most of them with 12…
Also, the cursor has not changed in the last days if I’m not mistaken.
Sure, though I don’t know if this is exactly correct. The rollout mechanism uses 2 values on version.storj.io they look like this.
"rollout":{"seed":"1c817a96cd45ef5e3c2467c1d98c399eeeba36ddc8436de0934370d3dcd8dba5","cursor":"3fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"}}
The cursor is just incremented gradually to phase the rollout. Now this is the part I’m not entirely sure on, but the updater hashes your nodeid + the seed and if the resulting hash is lower than or equal to the cursor, your node gets updated to the rollout version, otherwise the updater keeps (or gets) the suggested version.
It might not be a hash, but either way, the updater generates a unique value for your node based on the seed. The seed normally changes with each rollout, so the order of nodes who get the update first changes. There are some exceptions, like when a bugfix is released mid rollout, they usually keep the same seed so the nodes that already received the bugged version get updated first.
4 Likes
We discussed this internally and we have agreed to separate the Storagenode Docker image release from the Storagnode binaries release.
For that purpose, we created a new repository and we’ll move the Storagenode Docker to it.
We created a new issue in this new repository to explain why and what Move Dockerfile of storagenode out from storj/storj to here · Issue #1 · storj/storagenode-docker · GitHub
3 Likes
That is great news! Thanks for the update. This will save us a lot of unnecessary restarts and file walker processes.
In english please… 
What means this? Why there are fewer restars? Do we need watchtower still, for Docker nodes?
Edit: just read the link; it answered my questions. No need for watchtower than…
I don’t know why it says that. If there are docker image updates, you probably still want to install them automatically. But they shouldn’t happen unnecessarily with every release anymore. I think they meant to say you don’t need watchtower for storagenode updates anymore. But I personally still recommend using watchtower in case the docker image gets updated. @ifraixedes can you clarify/expand on this?
1 Like
It’s mostly what you said.
We won’t update Docker images on every new Storagenode release, we will only update it:
- If we need to change the Dockerfile or scripts copied into the Docker image for some reason.
- We need to update the Debian package because of known bugs, although we plan to do that update every defined certain period of time even if we are not aware of bugs.
If people want to update the Docker image automatically, they will have to use watchtower or a similar tool, however, I cannot say if Watchtower is a good or bad solution for auto-updating the Storagenode Docker image.
3 Likes