Hi, Colin, 1. Sounds good.
2. Yes, adding the listener fields will make it clear how BrokerRegistrationChangeRecord will be used. Thanks, Jun On Thu, Jun 3, 2021 at 4:34 PM Colin McCabe <cmcc...@apache.org> wrote: > On Thu, Jun 3, 2021, at 16:29, Jun Rao wrote: > > Hi, Colin, > > > > Thanks for the KIP. Just a couple of minor comments. > > > > Hi Jun, > > Thanks for taking a look. Sorry I just started the vote thread before I > saw this! :) > > > 1. Fields like RemovingReplicas are added as tagged fields in > > PartitionChangeRecord, but as non-tagged fields in PartitionRecord. > Should > > we make them consistent? > > > > I think it makes sense to make them normal fields in PartitionRecord, > since they will always be present there. In PartitionChangeRecord, these > fields will only be present if they are changing, so it makes sense to make > them tagged fields. > > > 2. Should we add BrokerRegistrationChangeRecord later when it has more > > fields than what's already covered in FenceBrokerRecord and > > UnfenceBrokerRecord? > > > > Hmm... eventually we want to have the ability to change the broker > endpoints dynamically (just like we can do in the ZK-enabled broker). That > will certainly belong in BrokerRegistrationChangeRecord. If I add this to > the record, does that give enough motivation to add it now rather than > later? I like the consistency of having a single change record. > > best, > Colin > > > > Jun > > > > > > On Wed, Jun 2, 2021 at 11:02 AM Colin McCabe <cmcc...@apache.org> wrote: > > > > > Hi all, > > > > > > I have posted a KIP about updating the KRaft metadata records for 3.0. > > > > > > Check it out at : https://cwiki.apache.org/confluence/x/34zOCg > > > > > > best, > > > Colin > > > > > >
