Yeah I agree that checking a majority of voters support the metadata.version is sufficient. What I was originally considering is whether (in the future) we could consider encoding the metadata.version value in the vote request as well, so that the elected leader is supposed to have a version that's supported by a majority of the quorum.
Guozhang On Tue, Nov 16, 2021 at 2:02 PM Colin McCabe <cmcc...@apache.org> wrote: > On Tue, Nov 16, 2021, at 13:36, Guozhang Wang wrote: > > Hi Colin, > > > > If we allow downgrades which would be appended in metadata.version, then > > the length of the __cluster_medata log may not be safe to indicate higher > > versions, since older version records could still be appended later than > a > > new version record right? > > > > That's fair... the longer log could be at a lower metadata.version. > > However, can you think of a scenario where the upgrade / downgrade logic > doesn't protect us here? > > Checking that a majority of the voters support the new metadata.version > we're going to seems to cover all the cases I can think of. I guess there > could be time-of-check, time-of-use race conditions, but they only happen > if you are doing a feature downgrade at the same time as a software version > downgrade. This is something the cluster management software should not do > (I guess we should spell this out in the KIP) I think nobody would want to > do that since it would mean rolling the cluster while you're messing with > feature flags. > > best, > Colin > -- -- Guozhang
