[jira] [Commented] (SOLR-16305) MODIFYCOLLECTION with 'property.*' changes can't change values used in config file variables (even though they can be set during collection CREATE)

["Vincent Primault (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764689#comment-17764689 ] 

Vincent Primault commented on SOLR-16305:
-----------------------------------------

I found this ticket while trying to understand the difference between MODIFYCOLLECTION and COLLECTIONPROP and the propagation flow of property.* properties. I was also surprised by the semantics of COLLECTIONPROP, which does not store the properties in cluster state, as opposed to similar user-defined properties for replicas which are indeed stored in cluster state (despite sharing the same API in v2).

For my use case, I would like to define some user-defined properties at the collection-level, and propagate them to the core. What I am missing is 1/ the fact that those properties are not stored with the collection, but only used when creating cores 2/ not reused when creating new shard or replicas for this collection. After defining the "foo" property when creating the collection, I would need further calls to ADDREPLICA to also reuse those collection-level user-defined properties.

My proposal is then the following:
 * Store user-defined properties in cluster state at collection-level (coming from create collection/modify collection)
 * Store user-defined properties in cluster state at replica-level (coming from create replica/add replica prop/delete replica prop)
 * Inherit from user-defined properties from collection and replica when creating cores.

I believe it makes sense to inherit from properties to ensure consistency between the first call creating a collection and first replicas, and the subsequent ones. It also gives semantics to modifying user-defined properties of a collection or replica: they do not affect existing cores, but all cores created after that.

> 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
>            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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org