Would the huge drop in traffic be related to Stefan or other tests?

Node Operators
21

What version am i suppose to run… i just updated to v0.35.3 which was the newest version it downloaded following the commands in the storj documentation.

Am i not suppose to run the
docker pull storjlabs/storagenode:beta command

how did you get version 1.01

personally i didn’t setup watchtower because i don’t want the system to update itself… because then i won’t be around to fix it if there is a problem updating.

usually one can run very old version of the storagenode software and still have a working node without seeing any adverse effects, or one could in v2… so autoupdate isn’t really needed, aside from for something like critical security issues fixes…

but i have yet to find a place to actually see which version of the docker storagenode container i’m suppose to be running … tsk tsk

22

I have an alert set up so I get an SMS when a new docker image version is available. I got the message tonight and updated in the morning with my usual script of docker stop, docker rm and docker pull.

23

must have been released shortly after i updated then… oh well the node is quite busy now… ill try to update it again when it isn’t this active… getting v1.0+ seems like a pretty wise choice tho…
i didn’t even get a mail for either v0.35.3 or v1.01 like i did for when they pushed updating to v0.34.6…

how did you setup the sms thing? is that a watchertower thing or something custom.

24

I use this script:

#!/bin/bash
t=`/usr/bin/curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:storjlabs/storagenode:pull" | cut -d'"' -f 4`
/usr/bin/curl -s -H "Authorization: Bearer $t" https://index.docker.io/v2/storjlabs/storagenode/manifests/beta | jq '.history[0].v1Compatibility | fromjson |.created'

It returns the date of the latest image available. My zabbix server runs that script once an hour and sends me an SMS if the returned value changes.

1 Like
25

Another way to do this is to make an account on uptimerobot.com, and add the ports of your nodes. Then it will automatically send you a message (email, Telegram, etc), when your node is down. For the repo, you should be able to watch the Storj repository on your github account, and you’ll get an email when a new version is released.
Still, this is assuming that watchtower updates the nodes automatically, and your docker images are not removed in the process. Which is not a perfect assumption it seems.

26

Allowing automatic random updates is just asking for more downtime, since the update will happen when I am sleeping, away etc. Yes, the node can go down during those times on its own, but why touch it? I can run the update script when I know that I will have time to fix any potential problems that are caused by the update.

27

I’ve not received any email from storj in a long time (i’ve checked spam/garbage) so I don’t know there is any new update.

is it still docker pull storjlabs/storagenode:beta we should use or have it changed ?

28

docker pull storjlabs/storagenode:beta works for me.

1 Like
29

maybe the update email only gets sent if the update is required for nodes to function correctly… tho i did get an update email for v0.34.6, but as far as i can tell any node running v0.3+ should work perfectly fine… or that’s the lowest version the satellites supposedly accepts.

so with that in mind, i’m not to sure about the critical update idea… but maybe
wouldn’t it be funny if that kind of stuff was well documented. xD

https://forum.storj.io/t/sno-flight-manual/

oh and no emails from storj here either atleast regarding updates, for like 14 days+

30

How do I start watchtower after I downloaded it? Sorry for that stupid question :frowning:

31

There should be a guide how to use it somewhere, but since I do not use Watchtower, I do not want to link you to outdated information.

32

Sorry, just wanted to answer myself. Found the solution :slight_smile: Thx

1 Like
33

Mine updated to v1.0.1 17hrs 9mins ago currently 15:29 gmt.

1 Like
34

This is true that this is indeed a risk for downtime, but I do think it is better for the network if everyone does have the automatic updates enables. In that case the Storj team would have more control over which node runs which software, and be able to deploy more evenly (linearly over 3 days), and closely monitor how the network reacts to this. According to the DevOps way, you want to be able to deploy as quick as possible (maybe even multiple times per day?), without having to worry about compatibility issues because some nodes still running on last month’s software because the admin is on holiday, or due to admins skipping versions (update path issues) and therefore could miss database/data restructure/cleanup queues.

Perhaps a Storjling can address this doubt?
What is the recommended way of updating the SNO docker image?

  1. manually to be able to intervene when issues arise
  2. The Watchtower docker image for automatic updates (risking downtime if something goes wrong)
35

You don’t have to wait for a Storjling to answer that. While I think there is a reasonable debate to be had about this. Their answer would be to let watchtower do its thing. To be fair, it’s what I’m doing as well and I’ve never had any issues with it so far.

2 Likes
36

Doubt they would updated nodes to fast, just in case problems arise…and to be sure not to strain the network.

not a big fan of automatic updates myself, but if they make my life easier and are shown to be reliable, then i’m not opposed to them either.

i do however like to look at stuff from a more natural perspective and there is strength in diversity, ofc it’s not always an advantage, but having nodes from many different versions, i believe would make the network more reliable against many things.

it’s nor unthinkable that such a system like watchtower could be hacked and made to push malicious code, so yeah i like to be the one to push the button, when i’ve verified that it most likely does what i want it to… xD

i doubt the storj team cares how we update…

37

That may be, but, according to the rules, I am responsible for all downtime, so, it stands to reason that I would want to minimize downtime. One of the ways to do i is to be present during an update since we all know that a problem is more likely to appear when something is “touched”,

If I have to wake up in the middle of the night because the node is down due to some kind of a problem with my hardware, well, that’s my problem, I should have used better hardware etc. If I have to wake up in the middle of the night because an automatic updater decided that this is the best time for an update and managed to fail, well, that’s a problem that could have been easily prevented.

1 Like
38

Yes, and this is exactly what just happened, so I’m tending to agree with you.
I think I’d be worth investing a bit of time in creating the some simple update scripts, and regain control over when updates are done.

Thanks for the discussion, @Pentium100, @BrightSilence, @SGC !

2 Likes
39

if one does have automatic updates, i prefer them to ask for permission to update, so basically one replaces the commands or clicks with one button press.
i suppose if one want to make it really fancy these days one could run some sort of video surveillance with facial recog and then verify that one is around when updating…

maybe ask over speakers and get permission to update over mic…
just to over complicate a simple button press… xD

well long story short… i think verification of permission to update is the most critical thing… anything else can be automated without causing any issues.
one just needs to be on standby and have time to deal with issues, should they arise…

40

say… maybe wrong place to ask… but the GUI client for windows will do the update automatically ya?.. since i can’t do a pull request like you guys on dockers…