[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17615992#comment-17615992
]
Chris M. Hostetter commented on SOLR-16305:
-------------------------------------------
{quote}AFAIK the propagation of `property.*` values to cores is accidental, the
original purpose (again, AFAIK) was to be able to set aux properties in the
`state.json`, ...
{quote}
Uh, no. that's not true at all.
Long before Solr had a concept of "collections" or "multi-cores" we had the
ability for {{solrconfig.xml}} to include named properties that could be
defined at run time via sysprops (like the {{custom.prop}} example from the
issue description). Then at some point we added multi-core support, _AND_
{{core.properties}} file support so that different cores could use the same
configs, but have different behavior based on diff values for the same named
property in their individual {{core.property}} files.
Then we added the "Core Admin API" which included ([and still
includes|https://solr.apache.org/guide/solr/latest/configuration-guide/coreadmin-api.html#create-core-parameters])
support for custom {{property.*}} params (when doing a CREATE Core) that get
written to the {{core.properties}} file for the core you create, and later when
we added the concept of "collections" and a CREATE "Collection Admin API"
(which delegates to the CoreAdmin API) we included that same functionalty: When
CREATEing a collection, you can specify custom {{property.*}} params that get
passed to the CREATE CoreAdmin command of every replica created.
*In short: The original motication behind {{property.*}} params in the
Collection API was to use pass them to the underlying CoreAdmin API*
{quote}However, even using these `property.*` values is half-broken, as I
recently discovered - it's supported in MODIFYCOLLECTION but not in CREATE, ...
{quote}
I think you mean the exact opposite of what you just said?
That's what this issue is all about: when you CREATE a collection the
{{properyt.*}} values _*ARE*_ propogated to the (initialy) created replicas)
but they can *_NOT_* be modified by MODIFYCOLLECTION...
It's trivial to demonstrate that that CREATE collection does in fact propogate
them to the cores...
{noformat}
hossman@slate:~/lucene/solr [j11] [branch_9x] $ find ./solr/packaging/build/dev
-name core.properties
./solr/packaging/build/dev/example/cloud/node2/solr/gettingstarted_shard1_replica_n4/core.properties
./solr/packaging/build/dev/example/cloud/node2/solr/gettingstarted_shard2_replica_n1/core.properties
./solr/packaging/build/dev/example/cloud/node1/solr/gettingstarted_shard1_replica_n6/core.properties
./solr/packaging/build/dev/example/cloud/node1/solr/gettingstarted_shard2_replica_n2/core.properties
hossman@slate:~/lucene/solr [j11] [branch_9x] $ find ./solr/packaging/build/dev
-name core.properties | xargs grep hoss
hossman@slate:~/lucene/solr [j11] [branch_9x] $ curl
'http://localhost:8983/solr/admin/collections?action=CREATE&name=test&numShards=2&property.hoss=foo'
{
"responseHeader":{
"status":0,
"QTime":1110},
"success":{
"localhost:8983_solr":{
"responseHeader":{
"status":0,
"QTime":527},
"core":"test_shard1_replica_n1"},
"localhost:7574_solr":{
"responseHeader":{
"status":0,
"QTime":523},
"core":"test_shard2_replica_n2"}},
"warning":"Using _default configset. Data driven schema functionality is
enabled by default, which is NOT RECOMMENDED for production use. To turn it
off: curl http://{host:port}/solr/test/config -d '{\"set-user-property\":
{\"update.autoCreateFields\":\"false\"}}'"}
hossman@slate:~/lucene/solr [j11] [branch_9x] $ find ./solr/packaging/build/dev
-name core.properties | xargs grep hoss
./solr/packaging/build/dev/example/cloud/node2/solr/test_shard2_replica_n2/core.properties:hoss=foo
./solr/packaging/build/dev/example/cloud/node1/solr/test_shard1_replica_n1/core.properties:hoss=foo
{noformat}
> MODIFYCOLLECTION with 'property.*' changes can't change values used in config
> file variables (even though they can be set during collection CREATE)
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16305
> URL: https://issues.apache.org/jira/browse/SOLR-16305
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16305_test.patch
>
>
> Consider a configset with a {{solrconfig.xml}} that includes a snippet like
> this...
> {code:java}
> <str name="param.check">${custom.prop:customDefVal}</str>
> {code}
> ...this {{custom.prop}} can be set when doing a {{CREATE}} command for a
> collection that uses this configset, using the {{property.*}} prefix as noted
> in the reg-guide...
> {quote}{{property.{_}name{_}={_}value{_}}}
> |Optional|Default: none|
> Set core property _name_ to {_}value{_}. See the section [Core
> Discovery|https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html]
> for details on supported properties and values.
> {quote}
> ...BUT....
> These values can *not* be changed by using the {{MODIFYCOLLECTION}} command,
> in spite of the ref-guide indicating that it can be used to modify custom
> {{property.*}} attributes...
> {quote}The attributes that can be modified are:
> * {{replicationFactor}}
> * {{collection.configName}}
> * {{readOnly}}
> * other custom properties that use a {{property.}} prefix
> See the [CREATE
> action|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> section above for details on these attributes.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
