The core discovery process is dependent on presence of core.properties file
in the particular directory.
You can have a script, which will traverse the directory structure of core
base directory and depending on env/host name, will either restore
core.properties or rename it to a different file.
The script will have to run before solr starts. So solr will see the
directory structures, but core.properties will be missing from directories
which you do not want to load (renamed as core.properties.bkp)
We are already using this approach to control core discovery in prod (we
have 40 plus cores and we co-host only a couple of them on a single server.
)
On 21 August 2014 04:41, Erick Erickson <erickerick...@gmail.com> wrote:
> OK, not quite sure if this would work, but....
>
> In each core.properties file, put in a line similar to what Chris
> suggested:
> properties=${env}/custom.properties
>
> You might be able to now define your sys var like
> -Drelative_or_absolute_path_to_dev_custom.proerties file.
> or
> -Drelative_or_absolute_path_to_prod_custom.proerties file.
> on Solr startup. Then in the custom.properties file you have whatever
> you need to define to make the prod/dev distinction you need.
>
> WARNING: I'm not entirely sure that relative pathing works here, which
> just means I haven't tried it.
>
> Best,
> Erick
>
> On Wed, Aug 20, 2014 at 3:11 PM, Ryan Josal <ry...@pointinside.com> wrote:
> > Thanks Erick, that mirrors my thoughts exactly. If core.properties had
> > property expansion it would work for this, but I agree with not
> supporting
> > that for the complexities it introduces, and I'm not sure it's the right
> way
> > to solve it anyway. So, it doesn't really handle my problem.
> >
> > I think because the properties file I want to load is not actually
> related
> > to any core, it makes it easier to solve. So if solr.xml is no longer
> > rewritten then it seems like a global properties file could safely be
> > specified there using property expansion. Or maybe there is some way to
> > write some code that could get executed before schema and solrconfig are
> > parsed, although I'm not sure how that would work given how you need
> > solrconfig to load the libraries and define plugins.
> >
> > Ryan
> >
> >
> > On 08/20/2014 01:07 PM, Erick Erickson wrote:
> >>
> >> Hmmm, I was going to make a code change to do this, but Chris
> >> Hostetter saved me from the madness that ensues. Here's his comment on
> >> the JIRA that I did open (but then closed), does this handle your
> >> problem?
> >>
> >> I don't think we want to make the name of core.properties be variable
> >> ... that way leads to madness and confusion.
> >>
> >> the request on the user list was about being able to dynamically load
> >> a property file with diff values between dev & production like you
> >> could do in the old style solr.xml – that doesn't mean core.properties
> >> needs to have a configurable name, it just means there needs to be a
> >> configurable way to load properties.
> >>
> >> we already have a properties option which can be specified in
> >> core.properties to point to an additional external file that should
> >> also be loaded ... if variable substitution was in play when parsing
> >> core.properties then you could have something like
> >> properties=custom.${env}.properties in core.properties ... but
> >> introducing variable substitution into thecore.properties (which solr
> >> both reads & writes based on CoreAdmin calls) brings back the host of
> >> complexities involved when we had persistence of solr.xml as a
> >> feature, with the questions about persisting the original values with
> >> variables in them, vs the values after evaluating variables.
> >>
> >> Best,
> >> Erick
> >>
> >> On Wed, Aug 20, 2014 at 11:36 AM, Ryan Josal <ry...@pointinside.com>
> >> wrote:
> >>>
> >>> Hi all, I have a question about dynamically loading a core properties
> >>> file
> >>> with the new core discovery method of defining cores. The concept is
> >>> that I
> >>> can have a dev.properties file and a prod.properties file, and specify
> >>> which
> >>> one to load with -Dsolr.env=dev. This way I can have one file which
> >>> specifies a bunch of runtime properties like external servers a plugin
> >>> might
> >>> use, etc.
> >>>
> >>> Previously I was able to do this in solr.xml because it can do system
> >>> property substitution when defining which properties file to use for a
> >>> core.
> >>>
> >>> Now I'm not sure how to do this with core discovery, since the core is
> >>> discovered based on this file, and now the file needs to contain things
> >>> that
> >>> are specific to that core, like name, which previously were defined in
> >>> the
> >>> xml definition.
> >>>
> >>> Is there a way I can plugin some code that gets run before any schema
> or
> >>> solrconfigs are parsed? That way I could write a property loader that
> >>> adds
> >>> properties from ${solr.env}.properties to the JVM system properties.
> >>>
> >>> Thanks!
> >>> Ryan
> >
> >
>
--
Thanks & Regards
Umesh Prasad
Search l...@flipkart.com
in.linkedin.com/pub/umesh-prasad/6/5bb/580/
