OmniaGM commented on a change in pull request #11431:
URL: https://github.com/apache/kafka/pull/11431#discussion_r737584380
##########
File path:
connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorMakerConfig.java
##########
@@ -183,12 +187,18 @@ public MirrorClientConfig clientConfig(String cluster) {
// fill in reasonable defaults
props.putIfAbsent(GROUP_ID_CONFIG, sourceAndTarget.source() + "-mm2");
- props.putIfAbsent(DistributedConfig.OFFSET_STORAGE_TOPIC_CONFIG,
"mm2-offsets."
- + sourceAndTarget.source() + ".internal");
- props.putIfAbsent(DistributedConfig.STATUS_STORAGE_TOPIC_CONFIG,
"mm2-status."
- + sourceAndTarget.source() + ".internal");
- props.putIfAbsent(DistributedConfig.CONFIG_TOPIC_CONFIG, "mm2-configs."
- + sourceAndTarget.source() + ".internal");
+
+ String separator =
originalsStrings().getOrDefault(REPLICATION_POLICY_SEPARATOR,
REPLICATION_POLICY_SEPARATOR_DEFAULT);
+ if (separator.equals("-")) {
Review comment:
> mm2-offsets.{source}.internal includes - so allowing dash as a
separator may be problematic
I am still not sure why this is problematic?
In your Jira, you mentioned the following
> MirrorMaker2 creates internal topics to track the offsets, configs, and
status of the MM2 tasks. But, these topics are not affected by a custom
'replication.policy.separator' settings - that is, these topics may be
replicated against the user`s intention.
This issue can easily be fixed by handling `.internal` in `isInternalTopic`
default implementation. I would suggest just doing this small fix instead.
I don't think we need to use the separator or replication policy to define
any of connect's topics as users have already a way to override them using
`<CLUSTER_ALIAS>.config.storage.topic`, `<CLUSTER_ALIAS>.offset.storage.topic`
and `<CLUSTER_ALIAS>.status.storage.topic` configs. No point of controlling the
same config in two different ways.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
