Is there in the meantime an easy or built-in way to determine vetting status?
Like any API call or info from the debug port that can be used?
I am aware of the success script but want to avoid to additional external apps if possible.
You can use this script to see it:
It uses the direct access to the DB. However, I’m not sure that you can do this via API.
@jammerdan I don’t think that we have.
What exactly do you want to know? If the node is vetted or not and when?
Basic information about whether a node is fully vetted or not, such as a true/false indicator, would be helpful already. Ideally, even better to have more detailed information in case the node is not yet vetted, like a progress percentage or the number of audits it has already passed.
1 Like
The /metrics debug endpoint has audit_success_count. If nothing has changed since last time I checked, 100 and above means vetted. Remember it’s per satellite.
1 Like
Thank you for providing feedback.
Adding progress percentage, number of audits will be cool, however, it will require more work, and we don’t have the resources to tackle it now.
But, we added the vetted date on this commit https://review.dev.storj.tools/c/storj/storj/+/17454
The field looks like this in the UI
3 Likes
This just add information clutter. Node getting vetted is a one time event, that happens early at the node lifecycle and never changes. Keeping the date it happened forever in the dashboard provides no actionable information, and it does not belong in the section with data that actually does change and is proving actionable insights, like suspension statuses.
Why not remove the vetted status altogether once the node is vetted?
1 Like
Personally, I’m more confused about showing and not showing something, because one has to retain that when not showing means something.
The vetted date doesn’t change, but doesn’t it help to know when a node is vetted when there is a risk of getting disqualified or not even vetted yet?
1 Like
Nodes normal state is vetted. It does not need to be remembered because it’s a normal expected, and final state. The vetting process is a one time thing that happens and will no longer occur again for the life of the node. So it’s appropriate to show the message while it is happening and remove it later — because the status cannot change anymore, it is not useful to monitor it and it does not need to be remembered.
I thought node can be disqualified anytime, including during the vetting? Otherwise what’s the point of vetting.
I agree to this. If it is possible to show the date then I would prefer this. Because with the information when a satellite has been joined, you can tell how long it has taken the node to get vetted which can provide additional valuable information at no additional cost.
Also if provided, it is easy to determine if there is a difference in ingress after vetting or not.
So yes, I think showing the date as vetting indicator is a good idea.
1 Like
How is this information valuable? It’s non actionable.
True cost is information noise.
1 Like
I imagine the situation of having several nodes, all of them with different vetted times, or even some of them not vetted. In the case of an incident, the operator has to decide which nodes to keep and abandon, and the vetted time can be one factor to consider.
I agree with the information noise, but it doesn’t look to me like too much noise, just one single field more. We could consider noise to show the 100% suspension, audit, and online to be noise, and only show them when they aren’t 100%.
Anyway, we can land it and improve it later. I’m the one providing it because of this request, and it turns out that there was already a ticket for it Add a node vetted status to SNO dashboard · Issue #5016 · storj/storj · GitHub, but it has to be reviewed and accepted, and I’m going to post a link to this post so your comments can be more visibile and hopefully considered by a broader audicence.
Thank @arrogantrabbit and @jammerdan for the constructive feedback and discussion
3 Likes
We already have people question why one node has 10GB more than other, and asking if it’s a problem, and what should they do?
If we add the vetting date, then they can ask why one node took 10 days longer than other, and ask if it’s a problem, and what should they do? 
I’m not against having vetting status in the UI… but I agree it’s such a temporary state it doesn’t seem to add value. From what I’ve seen US1 is usually done in a week, and the other satellites just a couple more.
2 Likes
I’m new to srorjnode and I don’t agree with you. It was very important information for me (using earnings.ph) to see that OK, I’m not vetted, but something is going on, I’m progressing. But sure, once you vetted one node, you don’t need it anymore. When/If I’ll create next node, most probably I’ll even not look at this 
2 Likes
But this is a very niche and contrived corner case. We should not design something that everyone sees in the UI for the niche corner case.
That’s called feature creep. One more thing here, one more thing there.
As the famous quote goes:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Yes, absolutely, 100% (pun not intended)! I have expressed this many times on this forum. Ideal dashboard is a big green circle 
saying “all is Ok”. That only provides any information when something isn’t. Information that would include last 20 lines of logs, that are often needed and requested by support here. That would be amazing UX. There is too much noise as it is.
It’s a fundamentally different approach to designing use interfaces — but node operators deserve good user experience too.
This just adds technical debt. You know that it will never be improved. The same way the plots that show daily bandwidths and fundamentally wrong (they must be a bar graphs and never interpolated to the current incomplete day) but are never going to be fixed.
You (as a company) don’t have to provide anything just because someone asked. There must be someone who makes UX decisions — let them get involved. Because right now satellite UI is amazing and node dashboard is garbage, honestly, both in presentation and usability.
Ultimately, or course it’s not my call, but it feels adding this would be a mistake…
I think at this stage the best turn of events would be if (1) node operators community stepped in and helped design and implement a better UI, (2) Storj Inc. openly accepted the patches. Storj Inc. doesn’t need a better UX, larger operators and select operators don’t use it anyway. I’m not using it myself unless rarely for basic diagnostics. Storj Inc. likely doesn’t know what would small operators need there either. Whether this is realistic, no idea, both on (1) and (2).
3 Likes
This. Storj has 28k+ nodes, growing around a dozen more each day, and SNOs will provide more capacity than they could ever resell.
- The Satellites need to be bulletproof and automated: so cheap for Storj to run.
- Customer UIs need to be featureful and easy to use… so they’re encouraged to use and pay.
- But node UIs can be sparse: SNOs are a dime-a-dozen: they’re here for money not an Apple experience
We’re fine with a chunk of .json from an API call… and just let the community stack on whatever reports they want. Don’t we have a couple free Grafana dashboards already?
3 Likes
Well… if node dashboard was useful, but not designed well — I would not have joined. So the crappiness of the dashboard is compensated by the lack of necessity to use it. I’ve changed banks, insurance providers, and credit card issuers because of their slightly annoying UI. Just to illustrate how seriously I’m taking this.
So yes. I do want Apple experience. I would not be tolerating anything lesser, not for proverbial $50/moneth.
That reinforces my other point - instead of spend time maintaining crappy and useless ui it’s better to get rid of it altogether.
Because when anything happens everyone asks for logs anyway.
For being useful for SNOs with multiple nodes like me, it would be required to be fetchable via API or debug endpoint. I hope this will be taken into account. I can’t even remember when was the last time I have looked at the dashboard because simple API call shows more useful information.
As far as I understand it the dashboard presents mostly data that can be fetched via API. Some sort of dashboard builder would be nice. I don’t know if something like this exists, a tool that creates individual dashboards based on json inputs. And I don’t mean something like Grafana.
1 Like
I just googled for dashboard builder and one of the first results was this:
Just to give an example what I mean. Maybe there is some open source tool like that that could be incorporated into the node software. With the node dashboard built on something like that, any SNO could either start their own or additional dashboard or change the existing one easily.