Normally if a newer client (CTL) sends a request to an older server with an unknown field, the server just ignores the field. While this gives us a lot of flexibility with forwards/backwards compatibility, sometimes we add new capabilities like #278 where we need to know if the server actually supports that functionality, and not submit the request if it is not supported.
To facilitate this we need to add GetCapabilities endpoints to Remote and Sync that return supported features like FEATURE_FILTER_FILES. Then if a command like beegfs remote push includes new flags like --filter-files we can have CTL confirm Remote supports that functionality and not issue the request if it is not supported.
On the Remote/Sync side the proposal is when Remote is connecting to Sync nodes as part of connect() before calling UpdateConfig (potentially instead of using a Heartbeat to get the peer IP) we call a new GetCapabilities() endpoint and if the Sync node doesn't support the same (or more capabilities) as the Remote node, we refuse to connect and retry with a normal backoff. This strategy ensures the Remote server can present a unified set of capabilities that the whole RST system currently supports.
We should also add a start timestamp to allow for easy detection when a service restarts and the client should refresh cached features. We also need to consider implications if the client caches these features indefinitely, generally these should be additive, but there may be implications for downgrades.
Normally if a newer client (CTL) sends a request to an older server with an unknown field, the server just ignores the field. While this gives us a lot of flexibility with forwards/backwards compatibility, sometimes we add new capabilities like #278 where we need to know if the server actually supports that functionality, and not submit the request if it is not supported.
To facilitate this we need to add
GetCapabilitiesendpoints to Remote and Sync that return supported features likeFEATURE_FILTER_FILES. Then if a command likebeegfs remote pushincludes new flags like--filter-fileswe can have CTL confirm Remote supports that functionality and not issue the request if it is not supported.On the Remote/Sync side the proposal is when Remote is connecting to Sync nodes as part of
connect()before callingUpdateConfig(potentially instead of using aHeartbeatto get the peer IP) we call a newGetCapabilities()endpoint and if the Sync node doesn't support the same (or more capabilities) as the Remote node, we refuse to connect and retry with a normal backoff. This strategy ensures the Remote server can present a unified set of capabilities that the whole RST system currently supports.We should also add a start timestamp to allow for easy detection when a service restarts and the client should refresh cached features. We also need to consider implications if the client caches these features indefinitely, generally these should be additive, but there may be implications for downgrades.