lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <>
Subject [jira] [Commented] (SOLR-7570) Config APIs should not modify the ConfigSet
Date Tue, 02 Jun 2015 07:37:22 GMT


Tomás Fernández Löbbe commented on SOLR-7570:

bq. But we have to find a sane way to share mutable configs and it is an extremely common
I agree with what I think Alan is saying here. In summary: 
* ConfigSets are all shareable meaning, you create a collection using a configset, it doesn't
matter if there are other collections already using it or not.
* Changes made via config APIs to a collection are specific to the collection where the request
was done. Changes are stored in /collections/$COLLECTION_NAME/conf. 
* Changes to configsets need a different API, or file upload. If I remember correctly, collections
are watching the configset znode, and may be reloaded after a watch is triggered. We should
keep this as a way to edit shared configsets, users would for example, upload a new solrconfig.xml
and then touch the configset. This should reload all collections using that configset as we
do now. 

> Config APIs should not modify the ConfigSet
> -------------------------------------------
>                 Key: SOLR-7570
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Tomás Fernández Löbbe
>         Attachments: SOLR-7570.patch
> Originally discussed here:
> The ConfigSet used to create a collection should be read-only. Changes made via any of
the Config APIs should only be applied to the collection where the operation is done and no
to other collections that may be using the same ConfigSet. As discussed in the dev list: 
> When a collection is created we should have two things, an immutable part (the ConfigSet)
and a mutable part (configoverlay, generated schema, etc). The ConfigSet will still be placed
in ZooKeeper under "/configs" but the mutable part should be placed under "/collections/$COLLECTION_NAME/…"
> [~romseygeek] suggested: 
> {quote}
> A nice way of doing it would be to make it part of the SolrResourceLoader interface.
 The ZK resource loader could check in the collection-specific zknode first, and then under
configs/, and we could add a writeResource() method that writes to the collection-specific
node as well.  Then all config I/O goes via the resource loader, and we have a way of keeping
certain parts immutable.
> {quote}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message