Release preparation v1.68

Product Discussions STORJLINGS
1

New release v1.68

Changelog

General

  • 591be92 .github: remove invalid codeowners
  • 954d703 ci: use check-cross-compile tool
  • 1d42f9a release v1.68.2

Satellite

  • 6273ed0 satellite/metabase: make UploadID stable for different options
  • 5f6b490 satellite/satellitedb: add columns last_offline_email and last_software_update_email
  • d856569 satellite/overlay: node software update email cooldown config
  • 2a25974 satellite/overlay: insert node software update events into node events
  • 5d4de3b web/satellite: properly position beta satellite checkbox
  • 6e77e09 satellite/nodeevents: add NodeEvents methods GetNextBatch, UpdateEmailSent
  • 5c2b111 web/satellite: filter out draft invoices
  • 97679a3 satellite/contact: emit evenkit events in case of node checkin
  • bc4cc49 satellite/satellitedb: exclude end date when calculating project totals
  • e769154 web/satellite: update all dropdown components to have the same interactions and states.
  • 3e5b527 web/satellite: VSearchAlternateStyling, VTableCheckbox migrated to use composition api
  • 9253e12 satellite/accounting: add missing monitoring
  • 5ef109f web/satellite: VTable default props console error fixed
  • 1d23c26 satellite/metainfo: add storj-downloader as a known user agent
  • 776f112 web/satellite: project level passphrase vuex logic
  • e339f1a satellite/console: enable session timeout by default
  • 1ad9126 satellite/metainfo: reduce log to warn
  • 8681a36 satellite/overlay: add ability to get offline nodes in need of email
  • c86340e satellite/satellitedb/dbx: change node_event read one to read first
  • 9fb18a4 satellite/metabase/rangedloop: observer interface
  • 57be07f satellite/nodeevents: add Chore
  • 705dfa0 satellite/nodeevents: add method Name to Type
  • ec77785 cmd/satellite: add segment-repair command
  • 87660bd satellite/overlay/offlinenodes: insert offline nodes into node events
  • 8d5a2a9 cmd/satellite: repair-segment; add option to process csv file directly
  • f84111e web/satellite: prevent token card text from overlapping elements
  • 1b67983 web/satellite: Fix filebrowser bugs in Firefox
  • c27563b web/satellite: analytics api calls moved to pinia store
  • 2ac5d16 cmd/satellite: fix repair-segment command args validation
  • 567557a satellite/orders: Remove period logs messages
  • 6c7f412 web/satellite: fix pop up position on safari
  • 3378215 satellite/orders: decrease order expiration time to 24hours
  • 9022506 web/satellite: allow execute permissions on wasm_exec
  • 8e9b773 cmd/satellite: repair-segment; don’t stop processing if segment is not found
  • d5eea2d satellite/accounting: use custom query for bucket tally by default
  • b574ee5 satellite/metabase/rangedloop: service skeleton
  • 8b494f3 satellite/audit: use db for auditor queue
  • 93bd1e2 web/satellite: reworked bucket tables
  • 0f995a7 web/satellite: add server-side encryption banner to new project dashboard
  • b063c53 satellite/audit: help performance of pushing to audit queue

Storagenode

  • f515629 storagenode/pieces: warn and trash v0 pieces when not found in v0pieceInfoDB

Uplink

  • 8c56986 uplink/share: support share via insecure authservice protocol
2 Likes
2

Nice to see these being picked up. Is this (and other changes related to this that I didn’t quote) now going live? It would be nice to get the more timely updates. Either way, thanks for implementing this!

This will help explain the difference seen in the graphs on the dashboard. It will be nice for customers to have final data in 24 hours in those graphs. :+1:

These pieces are still retrievable without the pieceinfodb file right? I’m just checking because we’ve always advised people that db’s are non-critical and can be replaced with empty ones if needed to fix a node. If that’s not the case for this db, we may need to adjust our advise in the future.
Also, is it possible to proactively migrate v0 pieces to v1? This might protect them against this scenario in the future (on nodes where the db is still in tact).

3

Is this mean, that payments can be also started form 3 days in new months?
today it only 4 day after month start

4

If I understand the code correctly (and my Go skills are rather weak), data from pieceinfodb are required at least for repairs and graceful exit.

There is a MigrateV0ToV1 function in the source code. Curiously though, it’s called only when a piece has to be moved to trash. The code doesn’t look complex, it could probably be easy to write a short Python script to reproduce the same.

1 Like
5

That is correct, it will be possible to start processing payouts on the 3rd of the month.

1 Like
6

the update broke quic for me

7

clementStorjling

3ore

I guess now is a good time to explain how the QUIC configuration check works starting from the release of v1.67.1.

We reimplemented how the QUIC check is done and that was introduced in this commit: storagenode: overhaul QUIC check implementation · storj/storj@59b37db · GitHub.
The commit message explains at high low, what was wrong and what we did to fix this.

The current implementation blocks the the startup until one or none
of the trusted satellites is able to reach the node via QUIC.
This can cause delayed startup. Also, the quic check is done
once during startup, and if there is a misconfiguration later,
snos would have to restart to node.

In this change, we reuse the contact service which pings the satellite
periodically for node checkin. During checkin the satellite tries
pinging the node back via both TCP and QUIC and reports both statuses.
WIth this, we are able to get a periodic update of the QUIC status
without restarting the node.

To be clear, it makes sense that a hard refresh changes the QUIC status. You don’t need to restart the node unlike before this change was introduced. We are reusing the contact service which periodically sends a checkin request to the satellite. The satellite then tries to ping back the node via both TCP and QUIC. If any of the satellites fails to ping back the node using QUIC, the dashboard will show the misconfigured status message which could also mean that your node was offline or checkin failed and will be retried or the UDP service port is actually misconfigured.

9

@Roberto it would be best to post the link to the original message: QUIC Misconfigured in v1.67.1 - #59 by clement

10

Sorry, I’m not familiar with forums and links, I thought I was good :smiley:

11

curl -s 192.168.0.82:14103/api/sno/satellite/12tRQrMTWUWwzwGh18i7Fqs67kmdhH9t6aToeiwbo5mfS2rUmo
{“error”:“consoleapi storagenode: console: sql: Scan error on column index 1, name "at_rest_total": converting NULL to float64 is unsupported”}

v 1.68.2

12

I observed this for some time on some nodes even on 1.67.3
here also have this error but only on 1 machine for some reason all other working
but 10 nodes on this one are show this error

13

Most often, this error occurs at the beginning of a new day. By the end of the day there are no such errors

14

I checked several times during the day.