For us we don't fully rely on cloud/collections api for creating and
deploying instances/etc.. we control this via an external mechanism so this
would allow me to have instances figure out what they should be based on an
external system.. we do this now but have to drop core.properties files all
ov
What’s the benefit? So you can avoid having a simple core properties file? I’d
rather see more value than that prompt exposing something like this to the
user. It’s a can of warms that I personally have not seen a lot of value in yet.
Whether we mark it experimental or not, this adds a burden, a
This is true. But if we slap big "warning: experimental" messages all over it,
then users can't complain too much about backwards-compat breaks. My intention
when pulling all this stuff into the CoresLocator interface was to allow other
implementations to be tested out, and other suggestions h
I think these API’s are pretty new and deep to want to support them for users
at this point. It constrains refactoring and can complicates things down the
line, especially with SolrCloud. This same discussion has come up in JIRA
issues before. At best, I think all the recent refactoring in this
I think solr.xml is the correct place for it, and you can then set up
substitution variables to allow it to be set by environment variables, etc.
But let's discuss on the JIRA ticket.
Alan Woodward
www.flax.co.uk
On 15 Jan 2014, at 15:39, Steven Bower wrote:
> I will open up a JIRA... I'm mo
I will open up a JIRA... I'm more concerned over the core locator stuff vs
the solr.xml.. Should the specification of the core locator go into the
solr.xml or via some other method?
steve
On Tue, Jan 14, 2014 at 5:06 PM, Alan Woodward wrote:
> Hi Steve,
>
> I think this is a great idea. Curre
Hi Steve,
I think this is a great idea. Currently the implementation of CoresLocator is
picked depending on the type of solr.xml you have (new- vs old-style), but it
should be easy enough to extend the new-style logic to optionally look up and
instantiate a plugin implementation.
Core loading
The work done as part of "new style" solr.xml, particularly by
romsegeek should make this a lot easier. But no, there's no formal
support for such a thing.
There's also a desire to make ZK "the one source of truth" in Solr 5,
although that effort is in early stages.
Which is a long way of saying
Are there any plans/tickets to allow for pluggable SolrConf and
CoreLocator? In my use case my solr.xml is totally static, i have a
separate dataDir and my core.properties are derived from a separate
configuration (living in ZK) but totally outside of the SolrCloud..
I'd like to be able to not hav
