There's a few decisions that need to be ironed out around the Solr docker image before 9.0 is released. This is because the community has decided that Solr should start releasing it's own docker images starting with 9.0.
Below is the current state of the ongoing discussions for the Solr Docker image. Please feel free to correct me or fill in any information I may be missing. Where does this image live? There are two options for this really. - _/solr - docker run solr:9.0 (Official Docker Image) - apache/solr - docker run apache/solr:9.0 The benefits of the first are 1) the nice usability of being able to plainly specify "solr" and 2) the "Docker Official Images" badge on DockerHub. The downsides are that there are very strict requirements with creating Official Docker Images, which would complicate and require separating the way that we build release docker images and local docker images. The benefits of using the apache namespace is that we can build the image in any way that we want. We would be able to build release and local docker images the exact same way. The downside is the loss of the "Docker Official Images" badge. *I think there is some consensus that choosing the "apache/solr" location is fine, and worth the added flexibility we get in the build process.* Legal Stuff There are a few legal questions we need to keep in mind when creating this process and doing a release for the first time. - Source release - The apache policy is: (from Michael Sokolov) “Every ASF release MUST contain one or more source packages, which MUST > be sufficient for a user to build and test the release provided they have > access to the appropriate platform and tools.” For the docker build this is fine as long as the solr/docker gradle module is included in the source release. As one can always rebuild the same image running gradlew docker using the source. - Jan Høydahl mentioned that the docker file layers should be limited, but I'm not exactly sure what this means or entails. Maybe he can expand on this. Artifacts within the Image As mentioned above in the "Image Location" section, the goal of including the docker build process inside the Solr project is to make development easier by providing an easy way to build the official-style docker image with local source code. In order to achieve "official-style" images for local builds, we want to make the build process for local images as close as possible to the process for building official release images. Currently the solr-docker-image, and a majority of "Docker Official Images", the officially released Solr binaries are downloaded from mirrors and validated within the Dockerfiles. This makes it easy to ensure to users that the 9.0 solr docker image contains the 9.0 solr release. This process doesn't fit very well with local builds, because there is nowhere to download local builds from, and validation isn't required. *The current opinion in the community is to abandon the "Docker Official Images" style process of downloading and validating official binaries, and instead having the release manager use the local-build image creation with the final release source.* This should result in the same docker image in the end, however there is no trust built into the docker image itself. Instead we are likely going to document a way for users to verify the docker-image contents themselves. I am not sure what the user-side verification process would look like for the image, but I definitely think it is something that we should look into. Maybe Docker will allow us to use these as official images if we can script out this verification and make it easy for them to do? Just a thought, I'm not sure if that would actually work.
