Thank you for your thoughtfulness, greg. 1. This configuration only relevant to the MirrorSourceConnector. 3. "disaster recovery" is what I saw Mickael Maison set up mentioned in this jira (https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-15172)). If you have any good suggestions, I can change the title of this KIP, thank you. 5. user scram credential: The topic acl information contains all related users, which can be parsed out, and then the SCRAM information of the source cluster and the target cluster can be obtained through "ApiKeys.DESCRIBE_USER_SCRAM_CREDENTIALS" and "ApiKeys.ALTER_USER_SCRAM_CREDENTIALS" respectively. group ACLs: List all the group acl of the source cluster, filter out all the group acl related to the relevant user in the previous step, and then use the admin interface to replicate to the target cluster. 6. I think it's a good idea to classify replication types, so it's more flexible to use, but I'm a little confused about what scenarios replicate only a few of them. (but it doesn't matter, it depends on the user)
I'm sorry, I don't understand your second and fourth questions. Could you describe them in detail? best, hudeqi "Greg Harris" <greg.har...@aiven.io.INVALID>写道： > Hi hudeqi, > > Thanks for the KIP! I think the original behavior (removing WRITE > permissions during the sync) is a good default, but is not acceptable > in every situation. I think providing a configuration for this > behavior is the right idea. > > I had a few questions: > > 1. Is this configuration only relevant to the MirrorSourceConnector? > Since we split the different connector configurations, we can omit > this configuration from the Checkpoint and Heartbeat connectors when > deployed in a connect cluster. > 2. Is this configuration only able to be configured globally for an > entire Dedicated MirrorMaker2? Can it be configured for one flow in a > dedicated deployment and not another by specifying > `source->target.sync.full.acl.enabled`? > 3. Is the documentation going to include the "disaster recovery" > language, or is that a left-over from an earlier revision in the KIP? > I don't think that "disaster recovery" is a very clear term in this > situation, and we should probably be very specific in the > documentation about what this configuration is changing. > 4. Did you consider any use-cases where a more restrictive ACL sync > would be desirable? Right now we are downgrading ALL/removing WRITE, > but leaving CREATE/DELETE/ALTER/etc ACLs as-is. Perhaps users would > like to choose between an ACL sync which is more locked-down, the > current behavior, or more permissive. > 5. Currently MM2 only syncs topic ACLs, and not group ACLs or SCRAM > credentials, so those would be new capabilities. Can you here (or in > the KIP) go into more detail about how these would work? > 6. Is there a reason to have one configuration control these three > different syncs? Could users want to change the topic ACL sync > semantics, while not using the group sync or the SCRAM sync? > > Thanks, > Greg > > On Mon, Aug 28, 2023 at 2:10 AM hudeqi <16120...@bjtu.edu.cn> wrote: > > > > Hi, all, this is a vote about kip-965, thanks. > > > > best, > > hudeqi > > > > > > > -----原始邮件----- > > > 发件人: hudeqi <16120...@bjtu.edu.cn> > > > 发送时间: 2023-08-17 18:03:49 (星期四) > > > 收件人: dev@kafka.apache.org > > > 抄送: > > > 主题: Re: [DISCUSSION] KIP-965: Support disaster recovery between clusters by MirrorMaker > > >
