Thanks for listing these out David. I think for the sake of 9.0, I choose (A). For 10.0 and beyond, I think I would prefer (B). You are right that if it is in it's own repo (C) it will not get much looks/releases. Which could be fine, but I think it's nice that it has to release with every Solr version for now (and therefore must maintain compatibility).
Either way for (B) or (C) it needs its own set of artifacts & docker file, but I agree with Jan, I don't think those would be particularly hard to solve. - Houston On Thu, Jan 13, 2022 at 6:57 AM Jan Høydahl <[email protected]> wrote: > 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 ) 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 > > >
