[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397735#comment-15397735 ] David Smiley commented on SOLR-7613: I agree with [~noble.paul] that solrcore.properties ought to be considered deprecated, and removed from 7x. I improved the documentation here to make config overlay more obvious https://cwiki.apache.org/confluence/display/solr/Configuring+solrconfig.xml and to steer people away from solrcore.properties. > solrcore.properties file should be loaded if it resides in ZooKeeper > > > Key: SOLR-7613 > URL: https://issues.apache.org/jira/browse/SOLR-7613 > Project: Solr > Issue Type: Bug >Reporter: Steve Davids > Fix For: 5.5, 6.0 > > > The solrcore.properties file is used to load user defined properties for use > primarily in the solrconfig.xml file, though this properties file will only > load if it is resident in the core/conf directory on the physical disk, it > will not load if it is in ZK's core/conf directory. There should be a > mechanism to allow a core properties file to be specified in ZK and can be > updated appropriately along with being able to reload the properties when the > file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[
https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735665#comment-14735665
]
Steve Davids commented on SOLR-7613:
I went ahead and swapped our {{solrcore.properties}} over to
{{configoverlay.json}} and it worked like a champ. Using the API we had the
chicken before the egg problem where the core wouldn't come up unless we had
some properties specified but we couldn't specify the properties without having
the core up and running. Thanks for the suggestion [~noble.paul], I think this
ticket is safe to be withdrawn.
> solrcore.properties file should be loaded if it resides in ZooKeeper
>
>
> Key: SOLR-7613
> URL: https://issues.apache.org/jira/browse/SOLR-7613
> Project: Solr
> Issue Type: Bug
>Reporter: Steve Davids
> Fix For: Trunk, 5.4
>
>
> The solrcore.properties file is used to load user defined properties for use
> primarily in the solrconfig.xml file, though this properties file will only
> load if it is resident in the core/conf directory on the physical disk, it
> will not load if it is in ZK's core/conf directory. There should be a
> mechanism to allow a core properties file to be specified in ZK and can be
> updated appropriately along with being able to reload the properties when the
> file changes (or via a core reload).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575908#comment-14575908 ] Noble Paul commented on SOLR-7613: -- Let's get rid of solrcore.properties in cloud . We don't need it. It is not just reading that thing. We need to manage the lifecycle as well (editing, refreshing etc) This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[
https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575915#comment-14575915
]
Noble Paul commented on SOLR-7613:
--
bq.In my particular case the core won't load without some of the properties
being specified. Is there a way to get those properties into ZK before you even
create the new collection? It looks like you are adding properties to an
already existing collection...
In these cases we normally provide a sane default in the config.
example {prop_name:prop_default_val}
The other option is to write directly to ZK before creating the collection ,
till we have a way to handle these outside of the collection
solrcore.properties file should be loaded if it resides in ZooKeeper
Key: SOLR-7613
URL: https://issues.apache.org/jira/browse/SOLR-7613
Project: Solr
Issue Type: Bug
Reporter: Steve Davids
Fix For: 5.3
The solrcore.properties file is used to load user defined properties for use
primarily in the solrconfig.xml file, though this properties file will only
load if it is resident in the core/conf directory on the physical disk, it
will not load if it is in ZK's core/conf directory. There should be a
mechanism to allow a core properties file to be specified in ZK and can be
updated appropriately along with being able to reload the properties when the
file changes (or via a core reload).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574208#comment-14574208 ] Alan Woodward commented on SOLR-7613: - I've been playing around with this a bit, and have come up with the following solution: the extra properties are loaded by the SolrResourceLoader, rather than in CoreDescriptor, which means that it's automatically loaded from the 'correct' place (and will allow overriding and editing when SOLR-7570 is in). Properties are only actually used by the resource loader, so there's no particular need for them to be available via CoreDescriptor anyway. I should have a patch to upload early next week. solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties In my particular case the core won't load without some of the properties being specified. Is there a way to get those properties into ZK before you even create the new collection? It looks like you are adding properties to an already existing collection... -Steve On Fri, Jun 5, 2015 at 12:09 AM, Noble Paul noble.p...@gmail.com wrote: Replying here coz jira is down Let's get rid of solrcore.properties in cloud . We don't need it. It is not just reading that thing. We need to manage the lifecycle as well (editing, refreshing etc) This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties On Fri, Jun 5, 2015 at 3:25 AM, Hoss Man (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573660#comment-14573660 ] Hoss Man commented on SOLR-7613: Some relevant comments on this from the original mailing list discussion... Hoss.. bq. IIUC CoreDescriptor.loadExtraProperties is the relevent method ... it would need to build up the path including the core name and get the system level resource loader (CoreContainer.getResourceLoader()) to access it since the core doesn't exist yet so there is no core level ResourceLoader to use. Alan... bq. I think this is an oversight, rather than intentional (at least, I certainly didn't intend to write it like this!). The problem here will be that CoreDescriptors are currently built entirely from core.properties files, and the CoreLocators that construct them don't have any access to zookeeper. bq. Maybe the way forward is to move properties out of CoreDescriptor and have an entirely separate CoreProperties object that is built and returned by the ConfigSetService, and that is read via the ResourceLoader. This would fit in quite nicely with the changes I put up on SOLR-7570, in that you could have properties specified on the collection config overriding properties from the configset, and then local core-specific properties overriding both. Hoss... bq. But they do have access to the CoreContainer which is passed to the CoreDescriptor constructor -- it has all the ZK access you'd need at the time when loadExtraProperties() is called. Alan... bq. Yeah, you could do it like that. But looking at it further, I think solrcore.properties is actually being loaded in entirely the wrong place - it should be done by whatever is creating the CoreDescriptor, and then passed in as a Properties object to the CD constructor. At the moment, you can't refer to a property defined in solrcore.properties within your core.properties file. Hoss... bq. but if you look at it fro ma historical context, that doesn't really matter for the purpose that solrcore.properties was intended for -- it predates core discover, and was only intended as a way to specify user level properties that could then be substituted in the solrconfig.xml or dih.xml or schema.xml bq. ie: making it possible to use a solrcore.prop value to set a core.prop value might be a nice to have, but it's definitely not what it was intended for, so it shouldn't really be a blocker to getting the same (original) basic functionality working in SolrCloud. Honestly, even ignoring the historical context, it seems like a chicken and egg problem to me -- should it be possible to use a solrecore.properties variable to set the value of another variable in core.properties? or should it be possible to use a core.properties variable to set the value of another variable in solrcore.properties? the simplest thing for people to udnerstand would probably be to just say that they are independent, loaded seperately, and cause an error if you try to define the same value in both (i doubt that's currently enforced, but it probably should be) solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to
Re: [jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
Replying here coz jira is down Let's get rid of solrcore.properties in cloud . We don't need it. It is not just reading that thing. We need to manage the lifecycle as well (editing, refreshing etc) This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties On Fri, Jun 5, 2015 at 3:25 AM, Hoss Man (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573660#comment-14573660 ] Hoss Man commented on SOLR-7613: Some relevant comments on this from the original mailing list discussion... Hoss.. bq. IIUC CoreDescriptor.loadExtraProperties is the relevent method ... it would need to build up the path including the core name and get the system level resource loader (CoreContainer.getResourceLoader()) to access it since the core doesn't exist yet so there is no core level ResourceLoader to use. Alan... bq. I think this is an oversight, rather than intentional (at least, I certainly didn't intend to write it like this!). The problem here will be that CoreDescriptors are currently built entirely from core.properties files, and the CoreLocators that construct them don't have any access to zookeeper. bq. Maybe the way forward is to move properties out of CoreDescriptor and have an entirely separate CoreProperties object that is built and returned by the ConfigSetService, and that is read via the ResourceLoader. This would fit in quite nicely with the changes I put up on SOLR-7570, in that you could have properties specified on the collection config overriding properties from the configset, and then local core-specific properties overriding both. Hoss... bq. But they do have access to the CoreContainer which is passed to the CoreDescriptor constructor -- it has all the ZK access you'd need at the time when loadExtraProperties() is called. Alan... bq. Yeah, you could do it like that. But looking at it further, I think solrcore.properties is actually being loaded in entirely the wrong place - it should be done by whatever is creating the CoreDescriptor, and then passed in as a Properties object to the CD constructor. At the moment, you can't refer to a property defined in solrcore.properties within your core.properties file. Hoss... bq. but if you look at it fro ma historical context, that doesn't really matter for the purpose that solrcore.properties was intended for -- it predates core discover, and was only intended as a way to specify user level properties that could then be substituted in the solrconfig.xml or dih.xml or schema.xml bq. ie: making it possible to use a solrcore.prop value to set a core.prop value might be a nice to have, but it's definitely not what it was intended for, so it shouldn't really be a blocker to getting the same (original) basic functionality working in SolrCloud. Honestly, even ignoring the historical context, it seems like a chicken and egg problem to me -- should it be possible to use a solrecore.properties variable to set the value of another variable in core.properties? or should it be possible to use a core.properties variable to set the value of another variable in solrcore.properties? the simplest thing for people to udnerstand would probably be to just say that they are independent, loaded seperately, and cause an error if you try to define the same value in both (i doubt that's currently enforced, but it probably should be) solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573660#comment-14573660 ] Hoss Man commented on SOLR-7613: Some relevant comments on this from the original mailing list discussion... Hoss.. bq. IIUC CoreDescriptor.loadExtraProperties is the relevent method ... it would need to build up the path including the core name and get the system level resource loader (CoreContainer.getResourceLoader()) to access it since the core doesn't exist yet so there is no core level ResourceLoader to use. Alan... bq. I think this is an oversight, rather than intentional (at least, I certainly didn't intend to write it like this!). The problem here will be that CoreDescriptors are currently built entirely from core.properties files, and the CoreLocators that construct them don't have any access to zookeeper. bq. Maybe the way forward is to move properties out of CoreDescriptor and have an entirely separate CoreProperties object that is built and returned by the ConfigSetService, and that is read via the ResourceLoader. This would fit in quite nicely with the changes I put up on SOLR-7570, in that you could have properties specified on the collection config overriding properties from the configset, and then local core-specific properties overriding both. Hoss... bq. But they do have access to the CoreContainer which is passed to the CoreDescriptor constructor -- it has all the ZK access you'd need at the time when loadExtraProperties() is called. Alan... bq. Yeah, you could do it like that. But looking at it further, I think solrcore.properties is actually being loaded in entirely the wrong place - it should be done by whatever is creating the CoreDescriptor, and then passed in as a Properties object to the CD constructor. At the moment, you can't refer to a property defined in solrcore.properties within your core.properties file. Hoss... bq. but if you look at it fro ma historical context, that doesn't really matter for the purpose that solrcore.properties was intended for -- it predates core discover, and was only intended as a way to specify user level properties that could then be substituted in the solrconfig.xml or dih.xml or schema.xml bq. ie: making it possible to use a solrcore.prop value to set a core.prop value might be a nice to have, but it's definitely not what it was intended for, so it shouldn't really be a blocker to getting the same (original) basic functionality working in SolrCloud. Honestly, even ignoring the historical context, it seems like a chicken and egg problem to me -- should it be possible to use a solrecore.properties variable to set the value of another variable in core.properties? or should it be possible to use a core.properties variable to set the value of another variable in solrcore.properties? the simplest thing for people to udnerstand would probably be to just say that they are independent, loaded seperately, and cause an error if you try to define the same value in both (i doubt that's currently enforced, but it probably should be) solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
