It's kind of a free-rider for sure, and a convenient one :) Ideally I'd like (C), but pragmatically for 9.0 I vote for (A) unless someone steps up with lots of energy :)
If we did C, there'd be a separate release artifact in CDN alongside solr-operator. <https://dlcdn.apache.org/solr/> The Dockerfile would be slim and simple, and the image could be pushed to apache/solr-prometheus-exporter, no need for "official" image? Jan > 13. jan. 2022 kl. 02:56 skrev David Smiley <[email protected]>: > > The inevitable rename of the "contribs" module to something else ( > https://issues.apache.org/jira/browse/SOLR-15917 > <https://issues.apache.org/jira/browse/SOLR-15917> ) will be a time for us to > move the prometheus exporter somewhere else, as it is not a module/package > within Solr; it's an independent service with its own dependencies; one of > which is SolrJ. It does not depend on Solr-core or such internals as it once > did. > > I just want to list some options here; perhaps there is another or a > variation. I suppose the last option is maybe the best but ultimately > someone would need to step up to the task. If nobody steps up (not me!), > then (A) will get done; it's very easy. > > (A) The least effort is merely to move it somewhere else in our directory > structure. If it's still under /solr, like /solr/prometheus-exporter, then > definitely very minor effort & impact. > > (B) More effort is to move to the top level of our source repo to distance > itself further from the Solr server. But that probably means it would not be > in our distribution, which also means it would not be in Solr's Docker image? > We could write a Dockerfile easily enough, I'm more unsure of how to publish > it and how much effort that is. > > (C) Even more effort is to outright move it to a new ASF git repo; to arrange > for CI (or just rely on GitHub Automation?). I'm unfamiliar with the effort > in all that. I could help with extracting source history in initializing the > git repo so we don't lose that. There is also the need to add a Dockerfile > and to publish it. The beauty of this is that it can have its own release > cycle! That means very few releases in practice. Although it means extra > work for actually doing these releases (voting, release-manager steps, > publishing), instead of a free ride on the Solr release train. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley>
