Jun, Thanks for the comments. Igor, please see 54 below for some additional discussion on the meta.properties
50.1 Yes, that field name sounds fine to me. 50.2 Ok, I'll add something to the KIP under the Controller section. To your other question, NoOpRecords are used as part of our liveness check for the quorum. It doesn't produce any metadata really, so I don't think it causes any harm to let it happen before the migration. KIP-835 has the details on the NoOpRecords 54. Colin and I discussed the meta.properties issue last night. How about we simply let the KRaft broker accept v0 or v1 meta.properties. At this point, the two versions have the same contents, but different field names. By leaving the meta.properties intact, we can simplify the downgrade process. If we care to, we could rewrite meta.properties once a broker is restarted after the migration is finalized (migration config disabled). 57. If a ZK broker can't send a BrokerRegistrationRequest because the quorum is unavailable, it should just continue operating normally. Once a leader is available, the broker will send the registration and start heart-beating. Unlike KRaft mode, we won't block startup on a successful BrokerRegistration response. Concretely, BrokerLifecycleManager will keep trying to contact the quorum in its own thread until the BrokerToChannelManager gets a controller ID from KafkaRaftManager. This shouldn't interfere with other ZK broker activity. -David > -- -David
