Changelog v1.24.4

Product Discussions STORJLINGS
8

Do you happen to know what the contents/format of the receipt field would be for zkSync payouts. I’m going to have to make some adjustments for this in the earnings calculator but haven’t switched to zkSync myself yet, so I would need an example.

Edit: Never mind, found it. Prefix will simply be zksync instead of eth. Simple enough. Looks like I’ll also be removing some warnings as there is a database migration included to fix missing distributed amounts for stefan-benten. Nice! That’ll clean up some historic misreporting.

9

I believe in the storage node database you would find something like this: zksync:0x260abd6959105bd8ad078d0d62563016d545e9a7c753cfed50178fec7246420c

The dashboard will link: https://zkscan.io/explorer/transactions/0x260abd6959105bd8ad078d0d62563016d545e9a7c753cfed50178fec7246420c

2 Likes
10

Edited my previous message just too late. Thanks though!

12

I believe we have that already. Maybe not on all satellites because they get migrated one by one. It doesn’t change our currnet deployment.

So lets assume we would have the “single point of failure” satellite with a postgres db in the background. The deployment process for such a setup was:

  1. Upgrade DB to the new version. Old API and core instances must be able to run with the new DB.
  2. Upgrade the API instances one by one. Hopefully the customer will not notice that the API instances are getting replaced with the new version. There should always be at least 1 API endpoint online.
  3. Last but not least upgrade core and any other process that is left.

Now the only difference in a multiregion satellite is the location. The deployment remains the same.

13

well actually according to previously announcements it’s 3 and pretty strict…
tho it does sort of become 4 because it’s 3 updates they count… and outside is DQ

so since when?
and why isn’t there like an easy place to get all these types of critical information…
kind of ridiculous we can’t even agree on what version we can be on before we get DQ.

should be pretty basic easy to check stuff…

1 Like
14

Thanks again! Update is live!

1 Like
15

You can see it on the dashboard, when you hover mouse over version number

16

that makes no sense…that version number has always been much lower than what this announcement told us was the lowest version else we would get DQ.
even when the post was made only 4 months ago… how are we suppose to know what do when the information given out in such a short timeframe is conflicting.

so we should just disregard what that post says?
and why would it even be written if it was wrong at the time it was written, was it just suppose to inform us about that version DQ was turned on… and the version thing is just how it will become at one point…

1 Like
17

I do not see any conflict - the lowest version of storagenode to join the network is 1.13.0. But minimum version to run a node is 1.22.2

18

Today I Learned that the 1.13.0 in the version mouseover is the minimal allowed to join the network. Would still like to see the minimum to receive ingress (currently 1.22.2) included in the mouseover.

1 Like
19

but a node with version 1.13.0 that joins the network gets DQ,
according to that statement, but maybe thats what you mean by joining the network…

or are you referring to that joining the network doesn’t mean on gets data
and running a node means that the node can get data…

but then again… why is the post giving out incorrect information at the time it was created…
since it can then still be more than 3 minor updates without getting DQ

if joining the network means you get DQ below this limit… maybe it should have a better name…
since not respecting that limit will destroy the node

2 Likes
20

I am still on 1.21.2 and have up- & downloads so far.
I think it is when the docker 1.24.4 version is released.

21

Any time I’ve been below the “storagenode: minimum: version:” listed in https://version.storj.io/ my ingress has flatlined, and I’ve been told I need to update to be properly taking part. Not sure how you’re working or if my understanding is incorrect.

22

I’m with @SGC on this one I must say, I’m very confused what versions disqualify nodes or not considering that hovering the version on the dashboard shows Running the minimal allowed version: 1.13.0: That is way more than 3 minor versions behind!

Did I miss something?

2 Likes
23

Why would we DQ old nodes and not just pause ingress like in the past?

24

I don’t know what Storj’s specific reason for drawing the lines where they have, but it is pretty standard for software vendors to require a certain minimum version for support. Known bugs, incompatibility with newer network features, etc. could be valid reasons to require being on a more recent version.

1 Like
25

I’m glad somebody brought up the question of minimum versions, I was going to ask about that. It is unclear how to get disqualified by just 1 version number.
A great and simple thing would be to simply show all the info on version tooltip.

“Latest software version is: vx.y.z
Limited ingress below this version: vx1.y1.z1
Node disqualification below this version x2.y2.z2”

4 Likes
26

It would be even greater if the color of the version number would change. Like green if version is up to date, yellow and orange if updates have been missed, red if no ingress anymore and maybe black if below minimum or something like that.

6 Likes
27

Yeah, that’s a great idea, simple and effective.
Maybe green for latest, green with “Update available” when 1 behind, then organge for no ingress and red if in danger of DQ.

28

@storgeez @jammerdan
Go rock that vote! And add suggestions if you have them!