I am unable to select a satellite in the SNOBoard for some reason. When I try to do so, the page simply reloads (to the same state as before), the “All satellites” satellite remains selected. I tried a hard page reload.
Which browser are you using ?
When I was using v1.21.1, then I had the same issue, but now on v1.21.2 it is working. (Using Chrome 88.0.4324.104 on Win 2019)
1 Like
Chrome and Firefox.
Will update to 1.21.2 then and retest, but there was nothing about it in the changelog so it shouldn’t make a difference.
Right, 1.21.2 fixed it, somebody forgot to add everything to changelog.
Or it was due to date no longer being 1st of the month.
We noticed the first bug last week while the rollout cursor was at 10%. We fixed the bug and pushed out a point release. The 10% that have updated to the new version will pick up the point release within 5 minutes. So there was not reason for additional messaging. This is exactly what our slow rollout process should cover.
For us the point release feels more like a regular release that 90% of the storage nodes will get over the following days. I try to write a changelog so that the storage nodes know what to expect from the new version. In this case the remaining 90% of the storage nodes haven’t seen the bug and so I didn’t mention the fix.
You can still find more details in the github changelog (release page) or even the full commit history. Just choose which one contains the information you are interested. We offer 3 levels so there should be one for everyone.
Beside that it sounds like you haven’t enabled automated updates? May I ask why?
That is a second bug and still not fixed. Next time it will happen again is in a month. We are not going to fix that with a point release.
2 Likes
Thank you for picking up the satellite selection storagenode dashboard issue and fixing it promptly.
If you change the suggested version on https://version.storj.io it is public and it will be picked up by someone. I for instance have my own updater that checks the suggested version every 6 hours and fetches any updates that I apply manually when I’m ready. My updater picked up and downloaded both the 1.21.1 and 1.21.2 releases as they were both set as the suggested version for a period of time.
There should be a formal changelog for every release (for at least an update for a point release) . This should really be part of your release process.
As for looking at the release in github - where does it mention this release fixes the satellite selection bug? ‘web/storagenode: remove uptime columns and references’ is not entirely helpful - I assume that was what was done to fix the issue - it doesn’t mention the issue itself. The formal Changelog has a different readership and purpose.
1 Like
Ah, so more like release notes than a changelog. Sorry, I usually step onto landmines by being affected by uncommon issues in any software, kinda gotten used to it by now. That’s why I check the changes first, if I don’t find it under changes I assume it’s something with my setup, I thought it’d disappear with a restart or something, but I reported it just in case.
The code itself is too much for me to examine/observe changes. I do read the Github changelog though.
I had the automated updates enabled at the very start and immediately stepped onto a landmine, as usual. Whole node went down, which would’ve happened anyway, but the worst thing was it was in the middle of the night and I did not see it until well into the next day (this was a time when permitted downtime was still under question).
Since then I have never enabled it again. I tried updating as infrequently as possible, but then it looked like I was not getting nearly as much data as usual after I was 2 versions behind (still well within the minimal version), so then I changed it to updating more frequently, at random. But this time it seems I’ve updated too fast. I’ll try to wait at least a week or so usually, but, you know… OCD.
Most importantly, there still aren’t any instructions, nor a way to autostart/stop for my OS on documentation.storj.io, so I didn’t touch anything that I didn’t have to until an official way was published, so that’s mostly why it’s still disabled.
So, in essence, manual updates because I can choose when, random events are a catastrophe for me. Most convenient thing would be to have an “Update” button in the SNOboard.
The node is only allowed to be 1 minor version behind the current release to receive data. 2 behind means no ingress. 3 behind is means your node will be disqualified.
You should really enable automatic updates again. There has been a lot of work done to mitigate some of the problems that can cause a node not to start after an update. I haven’t had any problems. And since the allowable downtime will be quite generous for the foreseeable future (and DQ for downtime is currently disabled), I would say the risk of being out of date outweighs the risk of your node not starting and possibly taking 8-12 or so hours to fix.
3 Likes
Thanks for the data, I must’ve forgotten or missed it. But I cannot be disqualified for running newer than minimal version, that makes no sense.
But, yeah, thanks, I will give the automatic updates another try in the future. As soon as there’s an official way to even run the node, I will plan thinking about considering enabling the updates.
Change logs are an art, not an exact science. If you include everything, it becomes an unreadable mess for most people. Also, nobody ever does this for good reason. That may mean that sometimes something might be left out that turned out to be relevant to more people than previously thought.
The change logs on github are aimed at a different audience. Developers mostly. There’s more detail, but it’s also more into the weeds.
I for one really appreciate the effort @littleskunk puts in the change logs posted here on the forums. The choices of what to include and leave out tend to be spot on. And considering that this impacted less than 10% of only windows nodes for like a day or two. I’d say he can be forgiven for not writing a separate change log for it.
1 Like
I appreciate the difference between what is posted as changes and the actual changes. But as user, this has anomalies, such as seeing something changed that isn’t in the changelog, and then you assume something’s wrong on your end and waste time. But now that you mention it, it IS a reasonable choice to include only what is expected to concern a user in an effort to declutter and simplify. Maybe just call it notable changes or release notes.
1 Like