VedarthConfluent commented on code in PR #16338:
URL: https://github.com/apache/kafka/pull/16338#discussion_r1641406413
##########
docker/examples/README.md:
##########
@@ -88,7 +96,7 @@ Single Node
- To run the example:-
```
# Run from root of the repo
- $ docker compose -f
docker/examples/jvm/single-node/plaintext/docker-compose.yml up
+ $ IMAGE=<image-name> docker compose -f
docker/examples/docker-compose-files/single-node/plaintext/docker-compose.yml up
Review Comment:
nit: I am fine with using variable for passing image name but the example
commands should be executable as it is imo. I think right now the person trying
to follow these steps will have to check the top documentation and put it
together to make a working command.
##########
tests/README.md:
##########
@@ -51,6 +51,19 @@ bash tests/docker/ducker-ak up -j 'openjdk:11';
tests/docker/run_tests.sh
```
REBUILD="t" bash tests/docker/run_tests.sh
```
+* Run tests with Kafka in `native` mode
Review Comment:
Will the system tests report generated using native mode will be included in
RC voting? Do we have any process where this will be ran as part of release or
on a regular basis? It's fine if it's currently not addressed but will be
addressed in future.
##########
docker/native/README.md:
##########
@@ -0,0 +1,31 @@
+# GraalVM Based Native Apache Kafka Docker Image
+
+## Introduction
+- The Native Apache Kafka Docker Image can launch brokers with sub-second
startup time and minimal memory footprint by leveraging native Kafka executable.
+- The native Kafka executable is built by compiling Apache Kafka code
ahead-of-time using the [GraalVM native-image
tool](https://www.graalvm.org/jdk21/reference-manual/native-image/).
+- This image is experimental and intended for local development and testing
purposes only; it is not recommended for production use.
+- This is introduced with
[KIP-974](https://cwiki.apache.org/confluence/display/KAFKA/KIP-974%3A+Docker+Image+for+GraalVM+based+Native+Kafka+Broker).
+
+## Native-Image reachability metadata
+The native-image tool performs static analysis while building a native binary
to determine the dynamic features(the dynamic language features of the JVM,
including reflection and resource handling, compute the dynamically-accessed
program elements such as invoked methods or resource URLs at runtime), but it
cannot always exhaustively predict all uses.
+To ensure inclusion of these elements into the native binary, reachability
metadata should be provided to the native-image builder.
+These metadata configs are provided in the `native-image-configs` directory.
+
+## How to generate reachability metadata
+GraalVM provide an option to create these configs automatically by running the
application normally with the [native-image
agent](https://www.graalvm.org/latest/reference-manual/native-image/metadata/AutomaticMetadataCollection/)
attached.
+The configs in the `native-image-configs` directory are generated by running
existing Apache Kafka System Tests(using GraalVM JIT and attaching the
native-image agent to the process) as they are quite exhaustive.
+
+## Limitations of Native Apache Kafka executable
+- Dynamic Features: For any new dynamic feature added or modified in Apache
Kafka, the corresponding metadata configurations must be added or updated in
the `native-image-configs`.
Review Comment:
I think this needs more details, to explain the steps to detect when the
configs need to be updated and how the configs will be updated.
Is it something that RM needs to check before releasing the graalvm image? I
think it would be good if we can clarify this.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
