SDK compatibility for cluster updates #40

Open
opened 2023-03-23 13:38:32 +00:00 by alexvanin · 2 comments
Owner

Consider cluster of FrostFS nodes. From time to time we update protocol version and some update may be compatible in terms of protobuf definitions but not compatible in terms of value interpretation (see __SYSTEM__ attribute in TrueCloudLab/frostfs-api#14).

We want to support rolling updates for FrostFS clusters. This means that FrostFS network may contain some new and some old versions of FrostFS node and gateways. So there are two requirements:

  1. New versions should not use new protocol features when talking to old nodes.
  2. New versions should not use new protocol features while consensus nodes are old (e.g. IR can't approve new __SYSTEM__* attribute).

So basically SDK client / pool should consider its own version, remote node version and network map (consensus) version and use min version to update request (for example replace new attribute with legacy attribute in container body).

Let's start doing this with all incoming protocol changes besides TrueCloudLab/frostfs-api#14.

Consider cluster of FrostFS nodes. From time to time we update protocol version and some update may be compatible in terms of protobuf definitions but not compatible in terms of value interpretation (see `__SYSTEM__` attribute in https://git.frostfs.info/TrueCloudLab/frostfs-api/issues/14). We want to support rolling updates for FrostFS clusters. This means that FrostFS network may contain some new and some old versions of FrostFS node and gateways. So there are two requirements: 1. New versions **should not** use new protocol features when talking to old nodes. 2. New versions **should not** use new protocol features while consensus nodes are old (e.g. IR can't approve new `__SYSTEM__*` attribute). So basically SDK client / pool should consider its own version, remote node version and network map (consensus) version and use _min version_ to update request (for example replace new attribute with legacy attribute in container body). Let's start doing this with all incoming protocol changes besides https://git.frostfs.info/TrueCloudLab/frostfs-api/issues/14.
Owner

Do you suggest doing something now is it a documentation change?

Do you suggest doing something now is it a documentation change?
Author
Owner

@fyrchik I would like to discuss and document the version sync approach between peers in this issue.

This issue highlights an interesting case, when protocol version negotiation should consider inner ring (network map) version too, e.g. for new 'well-known' attributes.

@fyrchik I would like to discuss and document the version sync approach between peers in this issue. This issue highlights an interesting case, when protocol version negotiation should consider inner ring (network map) version too, e.g. for new 'well-known' attributes.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-sdk-go#40
No description provided.