So I noticed that over 12 hours ago my complete ingress just stopped. Not even 1B/s occasionally, it was a flat line at 0 and the dashboard for today had 0B. (But there was the typcial repair ingress and egress was fine too, just no normal ingres)
All my 3 nodes were on 1.12.3, minimum required version is 1.9.0.
A restart of the nodes didn’t solve that.
As soon as I updated to 1.13.3 I got ingress again.
As 1.12.3 was still well above the minimum required version, this shouldn’t have happened. So why did it?
One thing to try is a complete refresh of the browser that you view the STORJ console in. Much of it seems to be published as cachable, which works fine until they do an update and change something. The browser then ends up using old cached content rather than the newer content.
I saw this with the Status and Suspension & Audit parts of the screen.
My nodes are still on 1.11.1 and I’m seeing exactly the same behavior, so I don’t think it’s specific to 1.12.3. Surely there are still customers uploading data?
Upgrading to 1.13.3 (the latest version available on Docker) does seem to have fixed the problem. Was it documented somewhere that the minimum version to receive uploads had changed?
We encourage to use the offically provided ways to update the nodes. That way they are kept up to date and in the version range that we allow. Uploads halting while downloads continue is either us encouraging you to update or that your disk is full.
The officially-provided way to do this on Linux is to give a container access to the Docker socket, which gives it full root access on the host. No, thank you. It is patently absurd to give a container root access to my whole system. That is an egregious violation of the principle of least privilege.
If the stance is that SNO’s should use the official recommendations, then there needs to be an officially-recommended way to accomplish this that doesn’t hand the keys to the whole host system over to a container.
yeah but if you run a version that was still above the minimum version then it is a bit weird/unfair. The minimum version according to the dashboard was 1.9.0 so there was no reason for me to update!
Besides, how am I supposed to know that my missing ingress is due to a too old version? (especially if I’m above the shown minimum version)
Not to mention the countless ways this update could fail or cause problems in your sleep… no thanks, I update manually when I feel like it/have the time to do so. That’s why we have a minimum allowed version. As long as I’m above that, I’m good.
The issue is, that once we bump that version your nodes will stop and refuse to start with the next problem. We have another satellite side minimum version in place, that makes sure older (close to the runtime allowed minimum) versions not get new data.
I can encourage you in your best interests, to use our update mechanism. It has a rollout feature built into to make sure not everyone at once updates.
i would happily use something like that if i selected when i would want it to update…
if it updates at random, then i cannot keep an eye on it and see if it running correctly after its done…
if there where a command or something like that a button which would update about when i ask it to, but did the check you talk of.
doesn’t matter to much if it takes 5-10minutes before it updates… ofc less is better… but if its all automatic it should be fine… i just manual update to check everything is okay after each update…
So you have a requirement that is not mentioned anywhere and that a SNO can’t see when looking at his node… I kindly request to change this policy!
Yeah I understand you. However, given the problems I encountered in the past, I will stay with the manual update process. After all, that’s why there is a minimum allowed version displayed, so I can stay within the allowed versions range.
It is not a requirement to operate the node. According to your comments above you operate according to the defined boundaries, which is accepted, but discouraged.
