I'd recommend building apache/solr:x.y.z as part of the normal solr release, then import those images into the official images library so that it also becomes solr:x.y.z. That way, you can move all the development/build/test work into your world (and deal with issues prior to release), and simplify the official publication step; and both can then be automated. This would remove a lot of toil from maintainers, and reduce the delay in image availability for our users, while retaining the "official image" badge and first-of-1600-matches listing on docker hub. It's then up to you which name you choose to promote in documentation, and whether to delay the release announcement till after the official image publication.
I don't know exactly what it takes for this to happen on the official-image library side, but it seems that Elastisearch does this [1]. I suggest Jan/David coordinate with @Tianon to see what is required in terms of verification, base images choice, rebuilding requirements and trigger mechanisms, and PR process changes. I would expect it to be fairly straightforward. Then there is a question about how to roll this out. Do it the new way from the next Solr major version, and maintain the current repo for older version for N years? Or have the new way produce older supported versions like 7 and 8? The latter would be nice but perhaps more work and more difficult to do in a backwards-compatible way. The docker-solr github org and repo namespace: it'd probably be best if they went away over time, assuming you can get what you need from the apache account in terms of administrative access. On the regular rebuilding of images: Per [2] I do believe the library team do rebuilds when a base image is updated, and thus tags are not immutable; but I don't have data to prove if and how often this happens. You can argue the desirability of that both ways; but given that an application like Solr, especially running in a JVM, is quite isolated from the host OS, I think it's more a feature than a bug, and would suggest we continue doing that for apache/solr builds. It does mean you have to have some automated tests to ensure that a new candidate image actually works before tagging it. Somewhat related: for docker-solr I also backported fixes to the helper scripts to images for older Solr versions, because the repo templating made that easy. If these scripts are moving into the Solr tree itself, then that won't be happening automatically, and I think that's fine. As to how exactly best implement the image building and publishing in your branch structure, build scripts and CI pipelines, I don't know; I'm not sufficiently familiar with those. But be careful with things like COPYing of tgz's, as that will lead to docker image layer wastage; doing something like a wget and extract in a single RUN command avoids that. There should also be a discussion on what base images to use and what variants to offer. On the one extreme is the notion that it should not matter what the base is because you only care about the application, on the other extreme there are always users asking for full OS images, slim variants, alpine versions, debian/redhat/whoknows base OS distributions, and all possible versions and distributions of Java, on all possible machine architectures. That leads to exploding build times, test matrices and maintenance overhead. I'd be tempted to just pick one official Java based on a current debian:slim, build for amd64 and 64bit arm and call it a day; but I've not looked at the Java image landscape recently. Having a Dockerfile example that users could use to install a Solr tgz on their own different base images might be useful. In response to Hoss' question about the initial choice to use _/solr and the github docker-solr org: I did that because there was a need for users to have Solr in a docker image that they could trust to be legitimate, would receive regular updates, would be respectful of backwards compatibility and would be functional enough for most use-cases. I could not have it in apache's namespace because that didn't exist, and the Solr project then wasn't really into Docker, or providing binary packaging for other third-party platforms. I did not want it in my or some other person's namespace (including my own) because that might lack credibility and would be problematic when they were no longer willing or able to provide updates. I did not want it in a company namespace because that could lead to misaligned interests. So by using _/solr, and setting up the docker-solr org, and getting buy-in from some Solr committers, I aimed to concentrate effort in a single community, and build trust and confidence in the image, and set things up so that they could easily be taken up by other Solr committers, or become part of the Apache Solr project, in future. So, it was a function of the circumstances at the time, and seems to have worked out pretty much as envisaged. -- Martijn [1] https://github.com/docker-library/elasticsearch/blob/master/7/Dockerfile [2] https://github.com/docker-library/official-images#library-definition-files --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
