Hi Shawn,

Yes, I'm running SolrCloud.

Meaning we have to create all the cores in the collection with the default
solrconfig.xml first?
Then we have to modify the core.properties, and rename the solrconfig.xml.
After which, we have to reload the renamed config to ZooKeeper, then reload
the collection?

We will need to customize our program for the client, which is why we
wanted to have our own unique config file.

Regards,
Edwin


On 27 February 2018 at 17:21, Shawn Heisey <elyog...@elyograg.org> wrote:

> On 2/27/2018 12:59 AM, Zheng Lin Edwin Yeo wrote:
>
>> Regarding the core.properties, understand from the Solr guide that we need
>> to define the "config" properties first. However, my core.properties will
>> only be created when I create the collection from the command
>> http://localhost:8983/solr/admin/collections?action=CREATE&;
>> name=collection
>>
>> The core.properties does not exists, and if I try to create one manually,
>> Solr will not read it, and it will still try to look for solrconfig.xml.
>>
>> What should be the right way to create the core.properties?
>>
>
> If you're running SolrCloud, you'll very likely have to allow it to create
> all the cores in the collection, then go back and modify the
> core.properties files that get created, and reload the collection once
> they're all changed.  If this actually works, keep in mind that the renamed
> config file is going to be loaded from zookeeper, right where
> solrconfig.xml would normally exist.
>
> Specifying options remotely in core.properties can only be done with the
> CoreAdmin API, but this is not used when in Cloud mode. The Collections API
> actually *does* use the CoreAdmin API behind the scenes, but because its
> usage in SolrCloud is very much an expert-level task, you shouldn't use it
> directly.
>
> The big question I have:  Why would you want to cause yourself difficulty
> by doing this?
>
> Thanks,
> Shawn
>
>

Reply via email to