Hi Ismael, Thanks for your good question. Answer them below: *1. Are we saying that every consumer upgraded would have to follow the complex path described in the KIP? * --> We suggest that every consumer did these 2 steps of rolling upgrade. And after KAFKA-12477 <https://issues.apache.org/jira/browse/KAFKA-12477> is completed, it can be reduced to 1 rolling upgrade.
*2. what happens if they don't read the instructions and upgrade as they have in the past?* --> The reason we want 2 steps of rolling upgrade is that we want to avoid the situation where leader is on old byte-code and only recognize "eager", but due to compatibility would still be able to deserialize the new protocol data from newer versioned members, and hence just go ahead and do the assignment while new versioned members did not revoke their partitions before joining the group. But I'd say, the new default assignor "CooperativeStickyAssignor" was already introduced in V2.4.0, and it should be long enough for user to upgrade to the new byte-code to recognize the "cooperative" protocol. What do you think? Thank you. Luke On Mon, Mar 29, 2021 at 12:14 PM Ismael Juma <ism...@juma.me.uk> wrote: > Thanks for the KIP. Are we saying that every consumer upgraded would have > to follow the complex path described in the KIP? Also, what happens if they > don't read the instructions and upgrade as they have in the past? > > Ismael > > On Fri, Mar 26, 2021, 1:53 AM Luke Chen <show...@gmail.com> wrote: > > > Hi everyone, > > <Update the subject> > > > > I'd like to discuss the following proposal to make the > > CooperativeStickyAssignor as the default assignor. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-726%3A+Make+the+CooperativeStickyAssignor+as+the+default+assignor > > > > Any comments are welcomed. > > > > Thank you. > > Luke > > >
