I checked the difference between the number of methods in the Admin interface and the number of methods MM2 invokes from Admin, and this diff is enormous (it's more than 70 methods). As far as I can see, the following methods MM2 depends on (in MirrorSourceConnector, MirrorMaker, MirrorCheckpointTask and MirrorCheckpointConnector), this will leave 73 methods on the Admin interface that customer will need to return dummy data for,
1. create(conf) 2. close 3. listTopics() 4. createTopics(newTopics, createTopicsOptions) 5. createPartitions(newPartitions) 6. alterConfigs(configs) // this method is marked for deprecation in Admin and the ConfigResource MM2 use is only TOPIC 7. createAcls(aclBindings) // the list of bindings always filtered by TOPIC 8. describeAcls(aclBindingFilter) // filter is always ANY_TOPIC_ACL 9. describeConfigs(configResources) // Always for TOPIC resources 10. listConsumerGroupOffsets(groupId) 11. listConsumerGroups() 12. alterConsumerGroupOffsets(groupId, offsets) 13. describeCluster() // this is invoked from ConnectUtils.lookupKafkaClusterId(conf), but MM2 isn't the one that initialize the AdminClient Going with the Admin interface in practice will make any custom Admin implementation humongous even for a fringe use case because of the number of methods that need to return dummy data, I am still leaning toward a new interface as it abstract all MM2's interaction with Kafka Resources in one place; this makes it easier to maintain and make it easier for the use cases where customers wish to provide a different method to handle resources. Omnia On Tue, Oct 26, 2021 at 4:10 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > I like the idea of failing-fast whenever a custom impl is provided, but I > suppose that that could be done for Admin as well. I agree your proposal is > more ergonomic, but maybe it's okay to have a little friction in such > fringe use-cases. > > Ryanne > > > On Tue, Oct 26, 2021, 6:23 AM Omnia Ibrahim <o.g.h.ibra...@gmail.com> > wrote: > > > Hey Ryanne, Thanks fo the quick feedback. > > Using the Admin interface would make everything easier, as MM2 will need > > only to configure the classpath for the new implementation and use it > > instead of AdminClient. > > However, I have two concerns > > 1. The Admin interface is enormous, and the MM2 users will need to know > the > > list of methods MM2 depends on and override these only instead of > > implementing the whole Admin interface. > > 2. MM2 users will need keep an eye on any changes to Admin interface that > > impact MM2 for example deprecating methods. > > Am not sure if adding these concerns on the users is acceptable or not. > > One solution to address these concerns could be adding some checks to > make > > sure the methods MM2 uses from the Admin interface exists to fail faster. > > What do you think > > > > Omnia > > > > > > On Mon, Oct 25, 2021 at 11:24 PM Ryanne Dolan <ryannedo...@gmail.com> > > wrote: > > > > > Thanks Omnia, neat idea. I wonder if we could use the existing Admin > > > interface instead of defining a new one? > > > > > > Ryanne > > > > > > On Mon, Oct 25, 2021, 12:54 PM Omnia Ibrahim <o.g.h.ibra...@gmail.com> > > > wrote: > > > > > > > Hey everyone, > > > > Please take a look at KIP-787 > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-787%3A+MM2+Interface+to+manage+Kafka+resources > > > > < > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-787%3A+MM2+Interface+to+manage+Kafka+resources > > > > > > > > > > > > > Thanks for the feedback and support > > > > Omnia > > > > > > > > > >
