Middleware 31525 docs: add kafka solution articles ported from internal Confluence #760
Open
yuhaosdl wants to merge 4 commits into
Open
Middleware 31525 docs: add kafka solution articles ported from internal Confluence #760yuhaosdl wants to merge 4 commits into
yuhaosdl wants to merge 4 commits into
Conversation
Contributor
WalkthroughAdded 47 new solution documentation pages across Kafka, RabbitMQ, and RocketMQ ecosystems. Pages cover SCRAM-SHA-512 authentication and authorization, cluster deployment and optimization, hot-standby disaster recovery with replication and monitoring, operational troubleshooting, data migration, and performance testing guidance. ChangesKafka Solution Documentation
RabbitMQ Solution Documentation
RocketMQ Solution Documentation
🎯 1 (Trivial) | ⏱️ ~3 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 15
🧹 Nitpick comments (5)
docs/en/solutions/ecosystem/kafka/Kafka_Topic_Delete_Data_Loss_Issue.md (1)
13-13: ⚡ Quick winClarify affected-version ranges to avoid overlap ambiguity.
The current statement mixes overlapping constraints (
ACP 3.10.xand<= 3.12.3), which can be read inconsistently. Please rewrite as explicit, non-overlapping ranges (for example by minor stream) so operators can determine impact unambiguously.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/solutions/ecosystem/kafka/Kafka_Topic_Delete_Data_Loss_Issue.md` at line 13, The "Affected versions" line ("Affected versions: ACP 3.10.x, <= 3.12.3, <= 3.14.2, <= 3.16.1. Fixed in ACP 3.12.4, 3.14.3, 3.16.2, and 3.18.") is ambiguous due to overlapping ranges; rewrite it into explicit, non-overlapping ranges by minor-stream (e.g., "ACP 3.10.x", "ACP 3.11.x up to 3.12.3", "ACP 3.13.x up to 3.14.2", "ACP 3.15.x up to 3.16.1") and then list the exact fixed releases ("Fixed in ACP 3.12.4, 3.14.3, 3.16.2, and 3.18") so operators can unambiguously determine impact — update the line in Kafka_Topic_Delete_Data_Loss_Issue.md replacing the original comma-separated constraints with these explicit minor-stream ranges.docs/en/solutions/ecosystem/rocketmq/RocketMQ_Exporter_Frequent_Restart_in_3121.md (1)
31-36: ⚡ Quick winConsider adding a concrete YAML example.
The solution describes increasing memory limits but doesn't provide a specific configuration example. Adding a YAML snippet showing how to adjust the exporter memory resources would make this guide more actionable for operators.
Example configuration snippet
spec: # Example: increase exporter memory exporter: resources: requests: memory: "256Mi" limits: memory: "512Mi"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/solutions/ecosystem/rocketmq/RocketMQ_Exporter_Frequent_Restart_in_3121.md` around lines 31 - 36, Add a concrete YAML example to the Solution section showing how to adjust exporter memory resources; insert a short snippet under the existing text demonstrating fields like spec.exporter.resources.requests.memory and spec.exporter.resources.limits.memory (e.g., requests: "256Mi", limits: "512Mi") so operators can copy/paste a ready configuration when increasing the exporter memory limit.docs/en/solutions/ecosystem/kafka/Kafka_Entity_Operator_Startup_Failure_Due_to_Container_Limits.md (1)
32-38: ⚡ Quick winClarify the scope of namespace default changes.
Increasing namespace default container limits affects all pods in the namespace, not just the entity operator. Consider adding a more prominent warning or suggesting a more targeted approach (e.g., patching the specific deployment if possible).
The current note at line 50 addresses this, but operators may not read ahead before executing the resolution steps.
Suggested addition
After line 34, add:
> **Warning**: Increasing namespace default limits will affect all new pods created in this namespace. Ensure the new defaults are appropriate for all workloads, or consider whether a more targeted fix is available for your platform version.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/solutions/ecosystem/kafka/Kafka_Entity_Operator_Startup_Failure_Due_to_Container_Limits.md` around lines 32 - 38, Add a prominent warning under the "Resolution" section that increasing namespace default container limits affects all pods in that namespace and recommend a more targeted fix when possible (for example patching the specific entity-operator Deployment/StatefulSet or adjusting the operator's PodSpec) before showing the kubectl delete pod step; ensure the warning appears immediately after the "Resolution" heading and clearly advises operators to validate other workloads or prefer patching the specific resource instead of changing namespace defaults.docs/en/solutions/ecosystem/kafka/Kafka_DR_Deployment_Guide_for_ACP_315.md (1)
107-107: ⚡ Quick winConsider using a more realistic
tasksMaxexample value.The example shows
tasksMax: 1, which provides minimal parallelism. While line 251 mentions tuning this parameter, a more realistic initial value (e.g., 3-5) would better represent production DR requirements and reduce the risk of users deploying with insufficient replication capacity.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/solutions/ecosystem/kafka/Kafka_DR_Deployment_Guide_for_ACP_315.md` at line 107, The example uses tasksMax: 1 which is too low for realistic DR deployments; update the example value for tasksMax (the Kubernetes job spec field labeled tasksMax) to a more realistic starting range such as 3–5 to better reflect production parallelism, and add a short inline comment or note near tasksMax to remind readers they should tune this value based on workload and available replicas.docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md (1)
69-81: 💤 Low valueConsider adding a note about ZooKeeper-based Kafka.
These commands use ZooKeeper (
--zookeeper,zookeeper.connect) for SCRAM credential and ACL management. This approach is appropriate for Kafka 2.7.0 and earlier versions but has been deprecated in favor of KRaft mode in newer Kafka releases. Consider adding a note that these commands are for ZooKeeper-based Kafka installations.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md` around lines 69 - 81, The documentation uses ZooKeeper-based commands (bin/kafka-configs.sh with --zookeeper and bin/kafka-acls.sh with --authorizer-properties zookeeper.connect) for SCRAM credential and ACL management; add a short note near these commands stating they apply to ZooKeeper-based Kafka (Kafka ≤2.7.0) and are deprecated for KRaft-based clusters, and suggest using the equivalent KRaft/admin APIs or newer kafka-configs/kafka-acls invocations for KRaft if applicable; reference the shown user sync-user so readers know these instructions target ZooKeeper-managed credentials and ACLs.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/en/solutions/ecosystem/kafka/How_to_Access_Kafka_with_Username_and_Password.md`:
- Around line 32-50: Update the Kafka manifest example by replacing the
unsupported hardcoded version value (the current `version:` entry) with a
supported ACP 3.x-compatible release such as `3.9.0` or `4.2.0`, and remove the
deprecated config key `log.message.format.version: "2.5"` from the `config:`
block; keep the rest of the `listeners:` and `authorization:` sections (e.g.,
`listeners`, `plain`, `external`, `tls`, `authentication`, and `authorization:
type: simple`) unchanged.
In
`@docs/en/solutions/ecosystem/kafka/How_to_Import_Kafka_Resources_From_Management_View.md`:
- Around line 45-50: The ctr run examples are missing the required container
name argument; update each ctr run invocation (the ones that use
build-harbor.alauda.cn/middleware/rdskafka-sync:1.0 followed by sh
./bin/check.sh) to insert a short container name/ID between the image and the
command (e.g., add "rdskafka-check" after the image and before "sh
./bin/check.sh") so the command syntax is valid; apply the same fix to the
second ctr run example later in the file.
In `@docs/en/solutions/ecosystem/kafka/How_to_Use_Kafka_Built_in_Test_Scripts.md`:
- Around line 62-64: The docs show creating a topic with "--replication-factor
5" which will fail if the Kafka cluster has fewer than 5 brokers; update the
guidance for the kafka-topics.sh examples by either lowering the
replication-factor to a safe default (e.g., 3) or adding an explicit
prerequisite note that the cluster must have at least 5 brokers before running
the command that creates "test_replication5" with "--replication-factor 5";
reference the example commands (kafka-topics.sh and the topic names
test_replication3/test_replication5) so the change is applied to the right
lines.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md`:
- Around line 87-91: The documentation writes the password to MY-PASSWORD.txt
and creates a Kubernetes secret but omits cleanup; after the kubectl create
secret generic sync-user-secret command add an instruction to securely remove
the plaintext password file (MY-PASSWORD.txt) using a secure delete (e.g., shred
or rm) to prevent credential exposure and mention verifying the file no longer
exists; reference MY-PASSWORD.txt and the kubectl create secret generic
sync-user-secret step so the cleanup step is placed immediately after secret
creation.
- Line 128: Update the KafkaMirrorMaker2 resource apiVersion in this document
from "kafka.strimzi.io/v1alpha1" to "kafka.strimzi.io/v1beta2" so it matches the
deployment guide; locate the apiVersion declaration in the KafkaMirrorMaker2
YAML block and replace the v1alpha1 string with v1beta2 to ensure consistency
across documents.
In `@docs/en/solutions/ecosystem/kafka/Kafka_DR_Deployment_Guide_for_ACP_315.md`:
- Around line 157-160: After creating the Kubernetes secret from the temporary
file, remove the plaintext file MY-PASSWORD.txt to prevent credential exposure;
update the steps around the kubectl create secret generic sync-user-secret call
to include a secure cleanup command (e.g., shred -u ./MY-PASSWORD.txt or rm -f
./MY-PASSWORD.txt) immediately after secret creation and optionally verify the
secret was created with kubectl get secret sync-user-secret.
In `@docs/en/solutions/ecosystem/kafka/Kafka_DR_Monitoring_and_Alerts.md`:
- Line 51: Update the documentation line that says "Import the MirrorMaker 2
dashboard JSON into the embedded Grafana after Prometheus starts scraping the
pod" to include a concrete reference to the dashboard JSON (e.g., a URL,
repository path, or bundled file name). Specifically, add a link or path to the
MirrorMaker 2 dashboard JSON (referencing the string "MirrorMaker 2 dashboard
JSON") and, if applicable, indicate the expected filename (for example
mirror-maker-2-dashboard.json) or the Grafana dashboard ID so users know exactly
where to obtain the JSON for import.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Hot_Standby_Disaster_Recovery_with_MirrorMaker2.md`:
- Around line 49-50: The example is using the removed Strimzi API version
kafka.strimzi.io/v1alpha1 for KafkaMirrorMaker2; update apiVersion to
kafka.strimzi.io/v1 and refactor the spec: replace occurrences of
.spec.connectCluster and .spec.clusters with the new .spec.target structure and
change mirror definitions so .spec.mirrors[].source references the target
cluster format expected by v1. Ensure KafkaMirrorMaker2 remains the Kind
referenced and adjust any field names/structures in the example to match the v1
API schema.
In `@docs/en/solutions/ecosystem/kafka/Kafka_ISR_Synchronization_Issues.md`:
- Around line 51-57: Update the Kafka CLI examples that use `--bootstrap-server
localhost:9092` (e.g., the `./bin/kafka-reassign-partitions.sh` snippet) to
clarify execution context: either state explicitly that these commands must be
run inside a Kafka broker pod/container (or a pod with network access to
brokers), or replace the localhost example with an in-cluster service FQDN
(e.g., `kafka-service.namespace.svc.cluster.local:9092`) and show both variants
(local container and bastion/jump-host) so readers know which endpoint to use
depending on where they run the commands.
In `@docs/en/solutions/ecosystem/kafka/Kafka_MetalLB_Access.md`:
- Around line 61-63: The producer example uses the deprecated flag
--broker-list; update the example invocation of kafka-console-producer.sh to use
the modern --bootstrap-server flag instead (locate the command line invoking
kafka-console-producer.sh and replace the --broker-list <external-ip>:9094 token
with --bootstrap-server <external-ip>:9094 so the example matches current
Kafka/Strimzi usage).
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Operator_Blocked_By_Abnormal_Instance.md`:
- Line 25: The current restart command uses --all-namespaces and thus restarts
all Strimzi cluster operators; change it to target only the operator's namespace
by replacing --all-namespaces with -n <operator-namespace> (or
--namespace=<operator-namespace>) so the kubectl delete pods command with label
selector strimzi.io/kind=cluster-operator only affects the affected operator
namespace.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Operator_Startup_Exception_After_314_Upgrade.md`:
- Line 35: The command currently deletes operator pods across all namespaces
using "--all-namespaces"; change it to target only the affected operator
namespace by replacing "--all-namespaces" with a specific namespace flag (for
example, "-n <affected-namespace>") so the line becomes: kubectl delete pods -n
<affected-namespace> -l strimzi.io/kind=cluster-operator; ensure you document or
parameterize the actual namespace name rather than using a cluster-wide
deletion.
In `@docs/en/solutions/ecosystem/rabbitmq/How_to_Use_RabbitMQ_Plugins.md`:
- Around line 72-74: The example lists rabbitmq_management_exchange under
additionalPlugins but doesn’t say it’s a community plugin that must be installed
separately; update the docs to either replace rabbitmq_management_exchange with
a built-in plugin (e.g., rabbitmq_management) in the example or add a clear note
next to additionalPlugins/envConfig stating that rabbitmq_management_exchange is
a community-maintained plugin requiring manual download/installation and
enablement, and include the required install/enable commands and link to the
plugin’s GitHub so users won’t hit silent enablement failures.
In
`@docs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Disaster_Recovery_Solution_Before_ACP_312.md`:
- Line 13: The phrase "Validated for ACP 3.8 era RabbitMQ deployments." uses a
compound adjective without a hyphen; update that text in the document (the line
containing "Validated for ACP 3.8 era RabbitMQ deployments.") to read "Validated
for ACP 3.8-era RabbitMQ deployments." so the compound adjective "ACP 3.8-era"
is hyphenated for correct technical writing consistency.
In
`@docs/en/solutions/ecosystem/rocketmq/How_to_Enable_External_Access_for_RocketMQ.md`:
- Around line 187-206: Add a concrete example showing how to configure the
broker’s advertised address in the broker StatefulSet: explain that you must set
the broker’s advertised host/IP in the pod spec (e.g., an environment variable
like BROKER_IP1 or by adding a JVM option such as -Drocketmq.broker.ip to the
container’s command/args) and show the same change alongside the
LISTEN_PORT/nodePort alignment discussed (refer to the StatefulSet manifest and
LISTEN_PORT/nodePort examples in the text); include one short snippet-style
example (env var or JVM arg) and mention validating the field name against your
operator/image before rollout.
---
Nitpick comments:
In
`@docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md`:
- Around line 69-81: The documentation uses ZooKeeper-based commands
(bin/kafka-configs.sh with --zookeeper and bin/kafka-acls.sh with
--authorizer-properties zookeeper.connect) for SCRAM credential and ACL
management; add a short note near these commands stating they apply to
ZooKeeper-based Kafka (Kafka ≤2.7.0) and are deprecated for KRaft-based
clusters, and suggest using the equivalent KRaft/admin APIs or newer
kafka-configs/kafka-acls invocations for KRaft if applicable; reference the
shown user sync-user so readers know these instructions target ZooKeeper-managed
credentials and ACLs.
In `@docs/en/solutions/ecosystem/kafka/Kafka_DR_Deployment_Guide_for_ACP_315.md`:
- Line 107: The example uses tasksMax: 1 which is too low for realistic DR
deployments; update the example value for tasksMax (the Kubernetes job spec
field labeled tasksMax) to a more realistic starting range such as 3–5 to better
reflect production parallelism, and add a short inline comment or note near
tasksMax to remind readers they should tune this value based on workload and
available replicas.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Entity_Operator_Startup_Failure_Due_to_Container_Limits.md`:
- Around line 32-38: Add a prominent warning under the "Resolution" section that
increasing namespace default container limits affects all pods in that namespace
and recommend a more targeted fix when possible (for example patching the
specific entity-operator Deployment/StatefulSet or adjusting the operator's
PodSpec) before showing the kubectl delete pod step; ensure the warning appears
immediately after the "Resolution" heading and clearly advises operators to
validate other workloads or prefer patching the specific resource instead of
changing namespace defaults.
In `@docs/en/solutions/ecosystem/kafka/Kafka_Topic_Delete_Data_Loss_Issue.md`:
- Line 13: The "Affected versions" line ("Affected versions: ACP 3.10.x, <=
3.12.3, <= 3.14.2, <= 3.16.1. Fixed in ACP 3.12.4, 3.14.3, 3.16.2, and 3.18.")
is ambiguous due to overlapping ranges; rewrite it into explicit,
non-overlapping ranges by minor-stream (e.g., "ACP 3.10.x", "ACP 3.11.x up to
3.12.3", "ACP 3.13.x up to 3.14.2", "ACP 3.15.x up to 3.16.1") and then list the
exact fixed releases ("Fixed in ACP 3.12.4, 3.14.3, 3.16.2, and 3.18") so
operators can unambiguously determine impact — update the line in
Kafka_Topic_Delete_Data_Loss_Issue.md replacing the original comma-separated
constraints with these explicit minor-stream ranges.
In
`@docs/en/solutions/ecosystem/rocketmq/RocketMQ_Exporter_Frequent_Restart_in_3121.md`:
- Around line 31-36: Add a concrete YAML example to the Solution section showing
how to adjust exporter memory resources; insert a short snippet under the
existing text demonstrating fields like spec.exporter.resources.requests.memory
and spec.exporter.resources.limits.memory (e.g., requests: "256Mi", limits:
"512Mi") so operators can copy/paste a ready configuration when increasing the
exporter memory limit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea60e1c2-c775-495a-b545-12cea324be3a
📒 Files selected for processing (40)
docs/en/solutions/ecosystem/kafka/How_to_Access_Kafka_with_Username_and_Password.mddocs/en/solutions/ecosystem/kafka/How_to_Import_Kafka_Resources_From_Management_View.mddocs/en/solutions/ecosystem/kafka/How_to_Run_Kafka_as_Root_User.mddocs/en/solutions/ecosystem/kafka/How_to_Use_Kafka_Built_in_Test_Scripts.mddocs/en/solutions/ecosystem/kafka/Kafka_24x_Not_Supported_After_ACP_312_Upgrade.mddocs/en/solutions/ecosystem/kafka/Kafka_AWS_NLB_Access.mddocs/en/solutions/ecosystem/kafka/Kafka_Best_Practices.mddocs/en/solutions/ecosystem/kafka/Kafka_Certificate_Expiry_Restart_on_ACP_3102.mddocs/en/solutions/ecosystem/kafka/Kafka_Cluster_Optimization_on_ACP_38.mddocs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.mddocs/en/solutions/ecosystem/kafka/Kafka_DR_Deployment_Guide_for_ACP_315.mddocs/en/solutions/ecosystem/kafka/Kafka_DR_Monitoring_and_Alerts.mddocs/en/solutions/ecosystem/kafka/Kafka_DR_Operations_Manual_for_ACP_315.mddocs/en/solutions/ecosystem/kafka/Kafka_DR_Validation_for_ACP_315.mddocs/en/solutions/ecosystem/kafka/Kafka_Entity_Operator_Startup_Failure_Due_to_Container_Limits.mddocs/en/solutions/ecosystem/kafka/Kafka_Hot_Standby_Disaster_Recovery_with_MirrorMaker2.mddocs/en/solutions/ecosystem/kafka/Kafka_ISR_Synchronization_Issues.mddocs/en/solutions/ecosystem/kafka/Kafka_MetalLB_Access.mddocs/en/solutions/ecosystem/kafka/Kafka_Node_Placement_Affinity_Taints_Guide.mddocs/en/solutions/ecosystem/kafka/Kafka_Operator_Blocked_By_Abnormal_Instance.mddocs/en/solutions/ecosystem/kafka/Kafka_Operator_Startup_Exception_After_314_Upgrade.mddocs/en/solutions/ecosystem/kafka/Kafka_Topic_Delete_Data_Loss_Issue.mddocs/en/solutions/ecosystem/rabbitmq/How_to_Run_RabbitMQ_as_Root_User.mddocs/en/solutions/ecosystem/rabbitmq/How_to_Use_RabbitMQ_Plugins.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Best_Practices.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_CPU_Imbalance_Across_Multiple_Instances.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_DR_Deployment_Guide.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_DR_Operations_Manual.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Data_Migration.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Disaster_Recovery_Solution_Before_ACP_312.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Exporter_Metrics_Collection_Solution.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Hot_Standby_Disaster_Recovery_with_Shovel.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_MetalLB_Access.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Migrate_From_38x_to_3124.mddocs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Node_Placement_Affinity_Taints_Guide.mddocs/en/solutions/ecosystem/rocketmq/How_to_Configure_RocketMQ_Console.mddocs/en/solutions/ecosystem/rocketmq/How_to_Enable_External_Access_for_RocketMQ.mddocs/en/solutions/ecosystem/rocketmq/RocketMQ_Deployment_Fails_With_Unvalidated_Storage.mddocs/en/solutions/ecosystem/rocketmq/RocketMQ_Exporter_Frequent_Restart_in_3121.mddocs/en/solutions/ecosystem/rocketmq/RocketMQ_Exporter_OOM_Temporary_Mitigation.md
Comment on lines
+32
to
+50
| version: 2.5.0 | ||
| replicas: 3 | ||
| listeners: | ||
| plain: | ||
| authentication: | ||
| type: scram-sha-512 | ||
| external: | ||
| type: nodeport | ||
| tls: true | ||
| authentication: | ||
| type: scram-sha-512 | ||
| tls: | ||
| authentication: | ||
| type: tls | ||
| authorization: | ||
| type: simple | ||
| config: | ||
| log.message.format.version: "2.5" | ||
| offsets.topic.replication.factor: 3 |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For the ACP 3.x + Strimzi versions this repository targets, what Kafka spec.kafka.versionvalues are officially supported, and islog.message.format.version still required/recommended?
💡 Result:
The repository likely targets Red Hat Streams for Apache Kafka (RHOK) 3.x + Strimzi, as "ACP" may refer to this distribution (no Confluent ACP uses Strimzi found). For RHOK 3.0 (Strimzi ~0.46.x), the primary supported Kafka version is 4.0.x (KRaft-only, ZooKeeper removed); Kafka 3.9.x supported only for upgrade [1][2][3]. For RHOK 3.1 (Strimzi ~0.48.x), Kafka 4.1 [4]. Recent Strimzi (0.45+ / 1.0+) supports Kafka versions marked 'supported: true' in kafka-versions.yaml, including 4.2.0 (default), 4.1.2, and older like 3.9.0-3.9.2, 3.8.0-3.8.1, etc., while dropping older ones progressively [5][6][7][8]. Full list from error messages/release notes (latest Strimzi 0.45.2): 4.1.1, 4.2.0, 4.0.0, 4.0.1, 4.1.0, 3.0.0, 3.2.3, 3.3.2, 3.4.1, 3.5.0, 3.5.1, 3.6.0, 3.5.2, 3.6.1, 3.7.0, 3.6.2, 3.7.1, 3.8.0, 3.0.1, 3.1.0, 3.1.1, 3.2.0, 3.1.2, 3.2.1, 3.3.1, 3.4.0, 3.8.1, 3.9.0, 3.9.1, 3.9.2 (among others older) [6][7]. Use spec.kafka.version with these exact strings; operator validates and pulls matching quay.io/strimzi/kafka images [9]. log.message.format.version is no longer required or recommended for supported Kafka 3.x/4.x in Strimzi. It was used in inter.broker.protocol.version < message format (e.g., pre-3.0 upgrades) to downgrade message format for compatibility, but for current supported versions matching broker capabilities, Strimzi configures modern defaults automatically without needing manual override [8][9][10]. No recent docs mention it as required; it's optional for legacy downgrade scenarios only.
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_streams_for_apache_kafka/3.0/html/release_notes_for_streams_for_apache_kafka_3.0_on_openshift/features-str
- 2: https://docs.redhat.com/en/documentation/red_hat_streams_for_apache_kafka/3.0/html/release_notes_for_streams_for_apache_kafka_3.0_on_openshift/ref-supported-configurations-str
- 3: https://docs.redhat.com/en/documentation/red_hat_streams_for_apache_kafka/3.0/html-single/release_notes_for_streams_for_apache_kafka_3.0_on_rhel/index
- 4: https://docs.redhat.com/en/documentation/red_hat_streams_for_apache_kafka/3.1/html-single/release_notes_for_streams_for_apache_kafka_3.1_on_openshift/index
- 5: https://github.com/strimzi/strimzi-kafka-operator/blob/main/CHANGELOG.md
- 6: https://github.com/strimzi/strimzi-kafka-operator/releases
- 7: https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.45.2
- 8: https://github.com/strimzi/strimzi-kafka-operator/blob/main/kafka-versions.yaml
- 9: https://strimzi.io/docs/latest/
- 10: https://github.com/strimzi/strimzi-kafka-operator/blob/master/cluster-operator/src/main/java/io/strimzi/operator/cluster/model/KafkaVersion.java
Replace hardcoded Kafka 2.5.0 with a supported version for ACP 3.x.
Kafka version: 2.5.0 is unsupported in ACP 3.x; current support matrix requires Kafka 3.x or 4.x (4.x preferred). Additionally, remove log.message.format.version: "2.5" entirely—it is no longer recommended for supported Kafka versions and serves no purpose in modern Strimzi deployments.
Update the example to use a currently supported version (e.g., version: 3.9.0 or 4.2.0) and remove the deprecated config key.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/How_to_Access_Kafka_with_Username_and_Password.md`
around lines 32 - 50, Update the Kafka manifest example by replacing the
unsupported hardcoded version value (the current `version:` entry) with a
supported ACP 3.x-compatible release such as `3.9.0` or `4.2.0`, and remove the
deprecated config key `log.message.format.version: "2.5"` from the `config:`
block; keep the rest of the `listeners:` and `authorization:` sections (e.g.,
`listeners`, `plain`, `external`, `tls`, `authentication`, and `authorization:
type: simple`) unchanged.
Comment on lines
+45
to
+50
| ctr run --rm \ | ||
| --mount type=bind,src=/root/.kube,dst=/root/.kube,options=rbind:rw \ | ||
| --net-host \ | ||
| build-harbor.alauda.cn/middleware/rdskafka-sync:1.0 \ | ||
| sh ./bin/check.sh | ||
| ``` |
Contributor
There was a problem hiding this comment.
ctr run examples are missing the required container name argument.
Both containerd commands will fail without a container ID/name between the image and command.
Suggested fix
-ctr run --rm \
+ctr run --rm \
--mount type=bind,src=/root/.kube,dst=/root/.kube,options=rbind:rw \
--net-host \
build-harbor.alauda.cn/middleware/rdskafka-sync:1.0 \
+ rdskafka-sync-check \
sh ./bin/check.sh-ctr run --rm \
+ctr run --rm \
--mount type=bind,src=/root/.kube,dst=/root/.kube,options=rbind:rw \
--net-host \
build-harbor.alauda.cn/middleware/rdskafka-sync:1.0 \
+ rdskafka-sync-run \
sh ./bin/sync.shAlso applies to: 68-73
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/How_to_Import_Kafka_Resources_From_Management_View.md`
around lines 45 - 50, The ctr run examples are missing the required container
name argument; update each ctr run invocation (the ones that use
build-harbor.alauda.cn/middleware/rdskafka-sync:1.0 followed by sh
./bin/check.sh) to insert a short container name/ID between the image and the
command (e.g., add "rdskafka-check" after the image and before "sh
./bin/check.sh") so the command syntax is valid; apply the same fix to the
second ctr run example later in the file.
Comment on lines
+62
to
+64
| ./kafka-topics.sh --create --bootstrap-server ${kafka_link} --topic test_replication3 --partitions 3 --replication-factor 3 | ||
| ./kafka-topics.sh --create --bootstrap-server ${kafka_link} --topic test_replication5 --partitions 3 --replication-factor 5 | ||
|
|
Contributor
There was a problem hiding this comment.
Call out broker-count prerequisite for --replication-factor 5.
Line 63 will fail unless the cluster has at least 5 brokers. Add an explicit prerequisite or use a safer example value to avoid a broken walkthrough.
Suggested doc fix
-./kafka-topics.sh --create --bootstrap-server ${kafka_link} --topic test_replication5 --partitions 3 --replication-factor 5
+# Requires a Kafka cluster with at least 5 brokers:
+./kafka-topics.sh --create --bootstrap-server ${kafka_link} --topic test_replication5 --partitions 3 --replication-factor 5🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/en/solutions/ecosystem/kafka/How_to_Use_Kafka_Built_in_Test_Scripts.md`
around lines 62 - 64, The docs show creating a topic with "--replication-factor
5" which will fail if the Kafka cluster has fewer than 5 brokers; update the
guidance for the kafka-topics.sh examples by either lowering the
replication-factor to a safe default (e.g., 3) or adding an explicit
prerequisite note that the cluster must have at least 5 brokers before running
the command that creates "test_replication5" with "--replication-factor 5";
reference the example commands (kafka-topics.sh and the topic names
test_replication3/test_replication5) so the change is applied to the right
lines.
Comment on lines
+87
to
+91
| ```bash | ||
| echo -n '<source-password>' > MY-PASSWORD.txt | ||
| kubectl -n <target-namespace> create secret generic sync-user-secret \ | ||
| --from-file=password=./MY-PASSWORD.txt | ||
| ``` |
Contributor
There was a problem hiding this comment.
Add password file cleanup instruction.
The password is written to a plain text file (MY-PASSWORD.txt) but no cleanup step is provided. Add a reminder to delete the file after secret creation to prevent credential exposure.
🛡️ Suggested addition
echo -n '<source-password>' > MY-PASSWORD.txt
kubectl -n <target-namespace> create secret generic sync-user-secret \
--from-file=password=./MY-PASSWORD.txt
+rm MY-PASSWORD.txt📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ```bash | |
| echo -n '<source-password>' > MY-PASSWORD.txt | |
| kubectl -n <target-namespace> create secret generic sync-user-secret \ | |
| --from-file=password=./MY-PASSWORD.txt | |
| ``` |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md`
around lines 87 - 91, The documentation writes the password to MY-PASSWORD.txt
and creates a Kubernetes secret but omits cleanup; after the kubectl create
secret generic sync-user-secret command add an instruction to securely remove
the plaintext password file (MY-PASSWORD.txt) using a secure delete (e.g., shred
or rm) to prevent credential exposure and mention verifying the file no longer
exists; reference MY-PASSWORD.txt and the kubectl create secret generic
sync-user-secret step so the cleanup step is placed immediately after secret
creation.
| ### 5. Create MirrorMaker 2 | ||
|
|
||
| ```yaml | ||
| apiVersion: kafka.strimzi.io/v1alpha1 |
Contributor
There was a problem hiding this comment.
API version inconsistency with deployment guide.
This file uses kafka.strimzi.io/v1alpha1 for KafkaMirrorMaker2, while Kafka_DR_Deployment_Guide_for_ACP_315.md (line 64) uses kafka.strimzi.io/v1beta2 for the same resource. For consistency and stability, both documents should use the same API version, preferably v1beta2.
📝 Suggested fix
-apiVersion: kafka.strimzi.io/v1alpha1
+apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| apiVersion: kafka.strimzi.io/v1alpha1 | |
| apiVersion: kafka.strimzi.io/v1beta2 | |
| kind: KafkaMirrorMaker2 |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_DR_Data_Migration_with_SCRAM_SHA_512.md`
at line 128, Update the KafkaMirrorMaker2 resource apiVersion in this document
from "kafka.strimzi.io/v1alpha1" to "kafka.strimzi.io/v1beta2" so it matches the
deployment guide; locate the apiVersion declaration in the KafkaMirrorMaker2
YAML block and replace the v1alpha1 string with v1beta2 to ensure consistency
across documents.
| Restart the Strimzi cluster operator and wait for reconciliation to resume: | ||
|
|
||
| ```bash | ||
| kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator |
Contributor
There was a problem hiding this comment.
Narrow restart scope to the affected operator namespace.
Line 25 uses --all-namespaces, which can restart unrelated Strimzi operators and broaden impact during incident handling. Scope this command to the specific operator namespace.
Suggested change
-kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator
+kubectl -n <operator-namespace> delete pod -l strimzi.io/kind=cluster-operator📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator | |
| kubectl -n <operator-namespace> delete pod -l strimzi.io/kind=cluster-operator |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Operator_Blocked_By_Abnormal_Instance.md`
at line 25, The current restart command uses --all-namespaces and thus restarts
all Strimzi cluster operators; change it to target only the operator's namespace
by replacing --all-namespaces with -n <operator-namespace> (or
--namespace=<operator-namespace>) so the kubectl delete pods command with label
selector strimzi.io/kind=cluster-operator only affects the affected operator
namespace.
| Restart the operator if it does not recover automatically: | ||
|
|
||
| ```bash | ||
| kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator |
Contributor
There was a problem hiding this comment.
Avoid cluster-wide operator pod deletion.
Line 35 deletes matching pods across all namespaces, which can disrupt unrelated operators. Restrict restart to the affected operator namespace.
Suggested change
-kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator
+kubectl -n <operator-namespace> delete pod -l strimzi.io/kind=cluster-operator📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| kubectl delete pods --all-namespaces -l strimzi.io/kind=cluster-operator | |
| kubectl -n <operator-namespace> delete pod -l strimzi.io/kind=cluster-operator |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/kafka/Kafka_Operator_Startup_Exception_After_314_Upgrade.md`
at line 35, The command currently deletes operator pods across all namespaces
using "--all-namespaces"; change it to target only the affected operator
namespace by replacing "--all-namespaces" with a specific namespace flag (for
example, "-n <affected-namespace>") so the line becomes: kubectl delete pods -n
<affected-namespace> -l strimzi.io/kind=cluster-operator; ensure you document or
parameterize the actual namespace name rather than using a cluster-wide
deletion.
Comment on lines
+72
to
+74
| additionalPlugins: | ||
| - rabbitmq_management_exchange | ||
| envConfig: | |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Is rabbitmq_management_exchange an official RabbitMQ plugin name? If not, what is the correct plugin identifier for exchange-related functionality (for RabbitMQ 3.12.x)?
💡 Result:
No, rabbitmq_management_exchange is not an official (core/tier 1) RabbitMQ plugin name. It is a community plugin hosted under the official RabbitMQ GitHub organization (rabbitmq/rabbitmq-management-exchange)[1][2]. It provides a special exchange type (x-management) for making HTTP requests to the RabbitMQ Management API via AMQP[1]. A v3.12.0 release exists, making it compatible with RabbitMQ 3.12.x[1].
Citations:
- 1: https://github.com/rabbitmq/rabbitmq-management-exchange
- 2: https://www.rabbitmq.com/community-plugins
Clarify that rabbitmq_management_exchange is a community plugin requiring separate installation.
rabbitmq_management_exchange is a community plugin maintained under the official RabbitMQ GitHub organization, not a built-in plugin. Using it in the example without noting that it requires separate installation may lead users to encounter enablement failures. Consider either replacing this with a standard built-in plugin or explicitly documenting the installation and setup requirements for community plugins.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/en/solutions/ecosystem/rabbitmq/How_to_Use_RabbitMQ_Plugins.md` around
lines 72 - 74, The example lists rabbitmq_management_exchange under
additionalPlugins but doesn’t say it’s a community plugin that must be installed
separately; update the docs to either replace rabbitmq_management_exchange with
a built-in plugin (e.g., rabbitmq_management) in the example or add a clear note
next to additionalPlugins/envConfig stating that rabbitmq_management_exchange is
a community-maintained plugin requiring manual download/installation and
enablement, and include the required install/enable commands and link to the
plugin’s GitHub so users won’t hit silent enablement failures.
| # RabbitMQ Disaster Recovery Solution Before ACP 3.12 | ||
|
|
||
| :::info Applicable Versions | ||
| Validated for ACP 3.8 era RabbitMQ deployments. |
Contributor
There was a problem hiding this comment.
Use compound adjective hyphenation for readability.
At Line 13, change “ACP 3.8 era” to “ACP 3.8-era” for standard technical writing consistency.
🧰 Tools
🪛 LanguageTool
[grammar] ~13-~13: Use a hyphen to join words.
Context: ...pplicable Versions Validated for ACP 3.8 era RabbitMQ deployments. ::: ## Introd...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/rabbitmq/RabbitMQ_Disaster_Recovery_Solution_Before_ACP_312.md`
at line 13, The phrase "Validated for ACP 3.8 era RabbitMQ deployments." uses a
compound adjective without a hyphen; update that text in the document (the line
containing "Validated for ACP 3.8 era RabbitMQ deployments.") to read "Validated
for ACP 3.8-era RabbitMQ deployments." so the compound adjective "ACP 3.8-era"
is hyphenated for correct technical writing consistency.
Comment on lines
+187
to
+206
| ## Update Broker Listener Ports and Advertised Address | ||
|
|
||
| After creating the Services, update each broker StatefulSet so the broker both: | ||
|
|
||
| - listens on the same port as the Service `NodePort` | ||
| - advertises a reachable external node IP or hostname instead of an in-cluster-only address | ||
|
|
||
| Changing the port alone is not enough. RocketMQ clients first contact NameServer and then connect to the broker addresses returned by NameServer metadata. If brokers still advertise pod IPs or other cluster-internal addresses, external clients will still fail. | ||
|
|
||
| For example: | ||
|
|
||
| - `broker-0-master` -> `LISTEN_PORT=30911` | ||
| - `broker-0-replica-1` -> `LISTEN_PORT=30912` | ||
| - `broker-1-master` -> `LISTEN_PORT=30913` | ||
| - `broker-1-replica-1` -> `LISTEN_PORT=30914` | ||
|
|
||
| Also set the broker's externally advertised IP or hostname to the node address that clients can actually reach. The exact field or environment variable name depends on the RocketMQ operator and image version in use, so verify it against the workload generated in your cluster before rollout. | ||
|
|
||
| If a port is already in use, choose a different port, but keep `port`, `targetPort`, and `nodePort` aligned for that broker. | ||
|
|
Contributor
There was a problem hiding this comment.
Provide the actual broker advertised address configuration fields.
The document correctly explains that brokers must advertise externally reachable addresses (lines 194-195), but line 203 states "The exact field or environment variable name depends on the RocketMQ operator and image version" without providing examples for any version. Add at least one concrete example showing how to set the advertised broker address (e.g., via environment variable or StatefulSet annotation) so users can adapt the pattern to their deployment.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/en/solutions/ecosystem/rocketmq/How_to_Enable_External_Access_for_RocketMQ.md`
around lines 187 - 206, Add a concrete example showing how to configure the
broker’s advertised address in the broker StatefulSet: explain that you must set
the broker’s advertised host/IP in the pod spec (e.g., an environment variable
like BROKER_IP1 or by adding a JVM option such as -Drocketmq.broker.ip to the
container’s command/args) and show the same change alongside the
LISTEN_PORT/nodePort alignment discussed (refer to the StatefulSet manifest and
LISTEN_PORT/nodePort examples in the text); include one short snippet-style
example (env var or JVM arg) and mention validating the field name against your
operator/image before rollout.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation