Docker Setup Flag
We modified the periodic filesystem check to verify the test file without creating it. The test file will be created during setup only. Let’s say you are mounting the wrong folder into the docker container. The old filesystem check would have continued as long as the mounted folder is read and writeable. The new check will error out because the test file is missing. This will prevent the storage node from failing audits.
For setting up a new docker node you have to add -e SETUP="true" once to create the test file and all the other storage node files. On the second run you have to remove that flag again or the storage node will refuse to start.
No action required for old docker nodes. You can keep your current docker run command.
For Satellite Operators
Multiple RS Scheme Support
The satellite is now able to handle multiple RS schemes at the same time. New uploaded files will always take what is currently in the satellite config. Old files will keep the old RS schema. The repair overwrite config accepts a list of RS schemes so that it can handle multiple repair overwrites. Up next we want to change the RS scheme, upload a set of test files, repeat that for each candidate, and finally collect and compare the repair costs of each RS scheme.
You can also run the setup step with --rm .
This will remove the container for you once it has finished. Otherwise, you will need to manually remove the container in order to create a new container for running the storagenode
hello, is it posible to setup some flag on windows? Needed for my toolbox, all versions after 19.5 dont create database files, havent jet understood how to make it.
–rm is kinda cool, but wouldn’t it also do so that if the storagenode crashes or is shutdown because of an issue, then the docker log would be deleted and thus lost for those that didn’t export their logs out of dockers.
anyway, something to keep in mind… might not be a good idea to recommend it as a default.
Even though it’s for the initial setup only, I think @SGC’s point stands: if the initialization run fails, it’d be good to have the logs to investigate what went wrong.
So I tend to agree it’d be better not to suggest using --rm by default.
Sure. But only advanced SNOs tend to redirect logs elsewhere and configure a bit more in depth their Nodes. That’s why I think that “by default” it shouldn’t be used, but you’re right logs should ideally be redirected elsewhere indeed.
@Storgeez: By default logs are handled by Docker so you can do whatever docker allows you to do within the scope of what logger plugins can do. If you decide to redirect node’s logs to a file (which is recommended), then you could mount the necessary folder so they are saved to your host as files, and then do whatever you want with them (logrotate for instance, …).
Yeah but see, the problem is, non-advancaed SNOs often come to the forum complaining about problems and when you ask for the logs, they are gone because they restarted the node. So even if you want to keep the logs in docker because of non-advanced SNOs, it is because of non-advanced SNOs that you actually need to have them redirected so you can help them in the first place…
but yes, if you redirect them by default, you might end up with people having 5GB of a logfile because they don’t implement a logrotate. So you’d at least need a file size check in the storagenode to delete a logfile if it gets bigger than 1GB.
the base docker logging solution isn’t that good, exporting or redirecting the logs to the storagenode data drive would costs more iops… which could be a problem… they could be located at the OS, that would also make multiple nodes store the logs in the same place.
i think docker can do log rotation by default, ofc that would complicate the install of the storagenode.
personally after a bit of testing, i ended up using daily log files… then it’s easy to use when processing them to compare stuff, check performance and look for issues and when they occured.
maybe we should create a thread for the development of a better default logging setup in docker, but i think part of the problem is that it would add additional complexity to the install.
watchtower will not update all nodes at the same time, it takes a few days before all nodes will have updated… and watchtower is linux and or docker which is still running 1.17.4 for a good week still
Watchtower usually starts updating nodes around the 5 to 7th day an so on. You can keep an eye on https://version.storj.io/ normally docker nodes get updated when its ffffffff… Windows GUI nodes get rolled out first.
