Right now rp-version-check.sh is responsible for curling a github api endpoint and determining if a newer version of the binary is available.
Realistically, there is no reason the node daemon can't do this, say, once per hour, and emit the rocketpool_version_update metric directly. Additionally, once it has been moved into the go code, rocketpool s start can also update the metric, so people no longer have to run sudo apt update after installing rocket pool in order to clear their grafana notification.
After this, the the update tracker will only be responsible for checking for system updates. Unfortunately this is a breaking change and requires all users of the update tracker to reinstall it with rocketpool s install-update-tracker after upgrading to the newest smart node. However, directionally, this is a good thing to tidy up, since it will allow us to do more sophistcated metrics (eg, add a metric called rocketpool_version_update_info with a label indicating the new version number, etc)
Ultimately we should be thinking about ways to remove the update tracker entirely, as it is incompatible with the smart node architecture we're trying to achieve (single daemon/api binary that combines rocketpool_node, rocketpool_api, rocketpool_watchtower).
Right now
rp-version-check.shis responsible for curling a github api endpoint and determining if a newer version of the binary is available.Realistically, there is no reason the node daemon can't do this, say, once per hour, and emit the
rocketpool_version_updatemetric directly. Additionally, once it has been moved into the go code,rocketpool s startcan also update the metric, so people no longer have to runsudo apt updateafter installing rocket pool in order to clear their grafana notification.After this, the the update tracker will only be responsible for checking for system updates. Unfortunately this is a breaking change and requires all users of the update tracker to reinstall it with
rocketpool s install-update-trackerafter upgrading to the newest smart node. However, directionally, this is a good thing to tidy up, since it will allow us to do more sophistcated metrics (eg, add a metric called rocketpool_version_update_info with a label indicating the new version number, etc)Ultimately we should be thinking about ways to remove the update tracker entirely, as it is incompatible with the smart node architecture we're trying to achieve (single daemon/api binary that combines rocketpool_node, rocketpool_api, rocketpool_watchtower).