I´m preparaing a migration of a node from Windows GUI to Linux.
I know it´s syncing the files (rsync) several times until it´s almost completed in a few minutes. Then stop the node, copy identity, DBs and final sync.
The issue I´m facing is that currently the Windows version is in 1.6.3, and the Docker one in 1.5.2. The database migration version is also different (42 in windows, 39 in linux), so i´m a bit concerned about if it´s possible to do the migration or i should wait until 1.6.3 release in Docker.
Would it be safe to use the 1.6.4 image tag before it hits the latest tag?
I saw the docker images generated by the CI are properly tagged, and there is one of the v1.6.4 branch/tag. Is it a final image or it can change before the release? I suppose it is better to wait for the release but… just wondering about those Docker images
So why is it that Windows seems to get all the attention with the upgrades? Seems it’s the priority. I look at the current version and wonder why my node is not updating. Would be good if there was a flag that told us when we should be updated and when it’s just a windows thing.
Well, that´s probably because Windows is one of the first OSes to get upgrades (alongside with other binary distributions that use the storagenode_updater mechanism) and also because there are a lot of SNOs running on Windows machines.
Also, I suppose Windows updates got more attention because the 1.6.3 update contains a bug pretty annoying for the SNO that caused the node termination.
That release was halted on the windows release phase and the issue was investigated and solved very fast by Storj team () , so there are some SNOs running on Windows and waiting for 1.6.4 to rollout in order to solve their issues:
In my particular case, I’m just trying to move away to a Linux and Docker releases, and it needs to be on the same version to do it in a safe way.
The answer is a lot simpler: On windows storjlabs can make the rollout of a new version a lot more controlled than on docker. With docker they have to publish the new image and then it is available for everyone. The recommendation is to use watchtower which randomly checks within 3 days for the new image. So docker is a lot less controllable than windows.
Therefore it makes sense to slowly roll out a new version to windows only and in the speed that they think might be right. If then a bug occurs, it’s typically the windows nodes that experience them because docker didn’t even get the update yet.
That may seem like the windows nodes get all the attention but it’s just a result of how the update rollout works. The windows port is definitely not more important than docker.
If you monitor your node with uptime robot, you’ll get a notification when something like that fails.
You’ll receive an email to update your node long before it becomes a problem that it’s running on an old version. For what it’s worth watchtower has never failed me. And I have several less techie friends running nodes who never look at them because they really wouldn’t know what to look at. They do monitor them with uptime robot, as do I, so I can contact them and help out if something goes wrong. This has not been needed so far.