Hey Ryanne, Thanks for the reply, personally I have a slight preference for my implementation since it doesn't require the "cheating" with the remote.topic.suffix as you mentioned (this also makes my implementation a bit more clean/simple) but I am definitely not opposed to adjusting to use your method in order to avoid needing KIP (however as you stated in order to get all usecases we would have to create a KIP later anyways).
What are your thoughts on seeing how the KIP works out, and if it takes too long or there is some issue with it we can go along with your implementation as an initial step? Though this is my first time doing a KIP so I am not sure how long it typically takes to get one approved. Regards On Wed, May 19, 2021 at 3:58 AM Ryanne Dolan <ryannedo...@gmail.com> wrote: > Hey Matthew, as you call out in the KIP there are few impls floating > around, including my WIP PR here: > > https://github.com/apache/kafka/pull/10652 > > The tests are currently passing except for a couple asserts related to > failback (commented out). It appears your PR doesn't address failback, so I > think we can consider the two impls functionally equivalent, more or less. > > However, I've cheated a bit here: I've added a "remote.topic.suffix" > property and have the integration tests configured to use it. So I can get > active/active replication to _mostly_ work with my impl, but that's not > really a requirement per se. It's fine with me if > Identity/LegacyReplicationPolicy explicitly only supports active/passive. > In that case, we can drop the "remote.topic.suffix" stuff, which would > require a separate KIP anyway. > > I think that means we can take my ReplicationPolicy (minus > remote.topic.suffix) and your tests and get to a working state without any > changes to the public interface, wdyt? > > Ryanne > > On Mon, May 10, 2021 at 6:02 PM Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > Hello everyone. > > > > I have a KIP that involves adding a public method to the > ReplicationPolicy > > interface called canTrackSource. The intention behind creating this > method > > is to implement an IdentityReplicationPolicy (aka > LegacyReplicationPolicy) > > which is a MirrorMaker2 ReplicationPolicy that behaves the same way as > the > > original MirrorMaker1 ReplicationPolicy. There is already a passing > > implementation at https://github.com/apache/kafka/pull/10648. > > > > It would be ideal for this change (if approved) to land for Kafka 3.0.0 > > since there is a change to a public interface but do not there aren't any > > breaking changes. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-737%3A+Add+canTrackSource+to+ReplicationPolicy > > > > Cheers > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
