SDK compatibility for cluster updates #40
Labels
No labels
P0
P1
P2
P3
good first issue
pool
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-sdk-go#40
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
__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.
Do you suggest doing something now is it a documentation change?
@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.