Heya, got a policy question for y’all.
Say I want to supplant a field from an
pErrto a more general message. This would break mixed-version clusters, as old nodes wouldn’t understand errors from new ones and vice-versa. I can populate both fields for the time being to work around this, but the question is how long are we supposed to maintain this? Just for one beta cycle? So is it OK to support upgrades from ver B to B+1, but not from B to B+2?
The specific field in question is
NotLeaseHolderError.LeaseHolder(the replica to which a request should be redirected), which I want to upgrade to a full
Leasefield (so I want to pass full information about the current lease in the error, as opposed to just the lease holder). This field is already optional in the proto and the code can deal with it missing in errors, but with some performance penalty in case a lease holder moves (the
DistSenderwouldn’t update the
LeaseHolderCacheon these errors). With this in mind, one options is to just screw old clients in order to save a followup code cleanup.
So the question here is, should we say it’s OK for clusters undergoing an upgrade to suffer some degree of degraded performance while the upgrade is ongoing? In other words, saying that one is supposed to finish a beta upgrade in a timely fashion after she’s started doing it, as opposed to being fine with mixed clusters indefinitely.