Storagenode API versioning

I’d like to ask for a API versioning because currently, we have to adapt all 3rd party monitoring tools within a short period of time with limited information about the changes (unless you go through the commits etc) and sometimes new API versions might even break something.

So to make the transitions between different storagenode/API versions easier, it would be great to have some basic API versioning, so we could still use the old API version until we got all changes for the new version implemented correctly.

Also btw @jocelyn I’m constantly out of votes because too many topics are still open/not enough votes available. Is it possible to change this?

hi @kevink I can check and see what settings are in place for that. I should also go through and close the voting on some of the older threads. Although I seem to remember uncovering some other edge case weirdness when i tried that before, i think it did some funny things to how the open votes were calculated.


Thanks jocelyn. I guess the easy way would be to increase the number of available votes. I’m unaware of any possible downsides in our case but maybe you know some.


yeah same here with the votes, they never seem to be released when stuff is implemented, closed or whatever.

@kevink was just thinking you where the man for this job, when i saw bright mention API versioning earlier, this is most certainly a good idea, since it will avoid a lot of future problems.

ok I will look at it either today or tomorrow. Its a super meetings-heavy week and i avoid multitasking when it comes to being in the admin settings, so I need to find a time when im not in a call – hope to clear it up soon though!


No hurry. Take your time and have good meetings!


I feel your pain. After 2 workdays I’ve had exactly an hour and a half to do some actual work. Can’t say that time was very productive in-between that. And please nobody mention the existence of email to me right now.

Anyway, yes it would be great if we could explicitly address an API version and have it work for a while longer when changes are implemented. Of course I still expect them to be deprecated at some point, but the overlap would give everyone the opportunity to to implement changes and test them on the new API version before things break.


Would be enough if old versions work for a few storagenode releases to give a few weeks.


@jocelyn Like many I’m facing this issue too, would be great to have more votes each, indeed!

With regards to this thread: versioning the APIs would be a great addition. But as @BrightSilence said they don’t have to live (and be maintained) forever.

Ok heres what I can do : I will increase the number of votes for now, and then I will go look at some of the old threads and see if I can close them out, which sshould also help bump up the allotments.
It appears that i already doubled the number of votes that the forum gives folks as the default. But we have a lot of topics and a lot of opinions to express, so i think it makes sense to do another round of customization on the settings. Sound good?

ETA: I just bumped all the levels, except for Trust Level 0. TL0 is the sandbox for new users, and it makes sense to keep that number low. However anyone who wants to move up to TL1 only needs to spend about 10 minutes browsing in the forum, so it shouldnt be a serious barrier for anyone who really wants to interact.


@kevink could you explain in more detail which APIs you are referring to, and what type of 3rd-party monitoring tools you’re using?

Generally what you find in commin/pb is (mostly) meant to be a stable API, whereas most of everything else is considered “internal” and not necessarily stable.

But if you could be a little more specific so I can understand which APIs you’re referring to, and what types of tools you’re using, we can see if there’s a way for us to be more specific about changes.

1 Like

I don’t know about him, but I thought of this when I voted for this idea:

I am monitoring audit socres and counts, but these are my own scripts and I should be able to quickly change them to use the new API after the update comes out. But for people using sripts written by someone else, those scripts will stop working until the author fixes them.
And there is no way to update those scripts now, because the nw API is not available. Ass soon as it is available the old API will stop working, so there is no transition period.

I’m talking about the api at http://localhost:14002/api/sno/… (e.g. /api/sno/satellites and /api/sno/satellite/satellite-id)
This could be versioned like /api/v0.1/sno/, /api/v0.2/sno/, etc

3rd-party monitoring tools: Prometheus Storj-Exporter - #157 by goldyka
With this tool we transform the api into prometheus compatible format so we can store the stats and display them using grafana.

Thanks for taking the time to think about it.