I've created SOLR-15954 <https://issues.apache.org/jira/browse/SOLR-15954> to track the work for Option A
On Fri, Jan 14, 2022 at 4:26 AM Jan Høydahl <[email protected]> wrote: > Big benefit of (B) is same release cycle as solr, perhaps same version, > piggy-back on releaseWizard (perhaps not even any new steps), auto test > with same version.. Guess this is kind of a mono-repo kind of choice. It's > different for solr-operator, different tech, built to support many solr > versions etc. > > But short term my vote is still (A) > > Jan > > 13. jan. 2022 kl. 16:47 skrev Houston Putman <[email protected]>: > > 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 >> >> >> >
