...

Image Naming

Image naming should :

...

transparently communicate the packaged Kafka version

...

.

Adhering to the outlined constraints, image tagging can follow this format
<image-name>:<kafka-version>-<optional-suffix>

• Name of the image: kafka
• For example, for 3.7.0 version of kafka, the image name with tagging would be apache/kafka:3.7.0In case of a CVE post 3.7.0, the name of the released image will depend on the section ReleaseProcess
  • apache/kafka:3.7.1 => Docker release along with Apache Kafka minor release
  • apache/kafka:3.7.0-1 => Only docker image release, hence added a suffix

Directory Structure

A new directory named docker will be added to the repository. This directory will contain all the Docker related code.
Directory Structure:

...

• For existing apache kafka users there will be no impact as JVM based docker image will be a new feature.

EOL Policy

...

We are not changing the EOL policy for the docker image and want to keep it inline with the Apache Kafka EOL Policy. We will support the last 3 releases(bug fix, CVE fixes etc).
Let's consider the following hypothetical scenario

...

.

...

Test Plan

• Testing the functionality of the Apache Kafka packaged in the image

  • The image will consist of the official tarball released by Apache Kafka.

  • The above tarball is pre tested as the part of Apache Kafka release.

  • Hence no extra testing is required for the Apache Kafka packaged in the image.

• Testing the Docker Image - Integration of the Apache Kafka with the Docker

  • Dockerizing Apache Kafka requires additional steps like, passing the configs from the user to the properties file in the container, passing credentials etc.

  • Sanity tests will be added to test the proper functionality of the docker image.

...

Following is the plan to release the Docker image(combination of 1 and 2):

1. Docker image release during AK release

   RM would have generated and pushed Apache Kafka's Release Candidate artifacts to apache sftp server hosted in Image Modifiedhome.apache.org by release.py script
2. Run the script to build the docker image(using the above Release Candidate tarball URL) and test the image locally.

3. The docker image needs to be pushed to some Dockerhub repo(eg. Release Manager's) for the evaluation of RC Docker image.

4. Start the Voting for RC, which will include the Docker image as well as docker sanity tests report.

5. In case any docker image specific issue is detected, that will be evaluated by the community, if it’s a release blocker or not.

6. Once the vote passes, the image will be pushed to apache/kafka with the version as tag.

7. Steps for the Docker image release will be included in the Release Process doc of Apache Kafka

8. eg. for AK release 3.7.0 and image released will be apache/kafka:3.7.0 (=> image contains AK 3.7.0)

9. Docker Image release post AK Release(eg CVE in the base image)
   Only Docker Image Release

   1. This step will be followed in case only Docker Image need to be released(eg CVE in the base image).

   2. Execute the script to build the docker image(using the already publicly released AK tarball URL) and test the image locally.

   3. Once the Docker image artifact is ready, it will get reviewed by the community and voting will be conducted, just for the Docker image release.

   4. This image will then be pushed to apache/kafka  with proper tagging to communicate kafka version.

   5. No AK release and image released will be apache/kafka:3.7.0-1 (=> image contains AK 3.7.0)

What if we observe a bug or a critical CVE in the released Apache Kafka Docker Image?

We should consider the software in the docker image in the same way as consider third party dependencies today - if there is a high severity CVE affecting any of them, we aim to release a new version of Kafka for the affected branch. It would include the latest Kafka code from the branch.

Ownership of the Docker Images' Release

...

Apart form the aforementioned approach we also considered the following approach

Complete Apache Kafka release along with Docker Image release during CVEs
Only Docker Image releaseRelease

...

1. This step will be followed in case only Docker Image need to be released(eg CVE in the base image).

2. Execute the script to build the docker image(using the already publicly released AK tarball URL) and test the image locally.

3. Once the Docker image artifact is ready, it will get reviewed by the community and voting will be conducted, just for the Docker image release.

4. This image will then be pushed to apache/kafka  with proper tagging to communicate kafka version.

5. No AK release

...

1. and image released will be apache/kafka:3.7.0-1 (=> image contains AK 3.7.

...

1. 0)