[
https://issues.apache.org/jira/browse/SOLR-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579558#comment-14579558
]
Gregory Chanan edited comment on SOLR-7570 at 6/9/15 8:59 PM:
--------------------------------------------------------------
bq. I guess you guys are missing the point here. What I'm suggesting is make
the mutable conf location configurable on a per collection basis. By default
(if no extra param is passed) it will be /collections/$COLLECTION_NAME/conf .
This will enable users to reuse mutable conf too. For example , when I create a
collection I can specify mutableconfdir=/collections/commonConfDir/conf and
every collection which has the same property will share the same node for
mutable configs
as far as I understand it, this suggestion is addressing tomas' bullet above:
{code}
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.
{code}
i.e. you need a place to share mutable configs. It seems cleaner to have a
separate ConfigSet API, i.e. REST calls to, say, /configs/MySharedConfig rather
than to alias collection-specific APIs. The later just gets us back to the
case we are in now, where collection-specific APIs can result in changes
outside the collection. That is confusing IMO.
edit: and the configs under /configs/xxx can be mutable or not, as described in
SOLR-5955.
was (Author: gchanan):
bq. I guess you guys are missing the point here. What I'm suggesting is make
the mutable conf location configurable on a per collection basis. By default
(if no extra param is passed) it will be /collections/$COLLECTION_NAME/conf .
This will enable users to reuse mutable conf too. For example , when I create a
collection I can specify mutableconfdir=/collections/commonConfDir/conf and
every collection which has the same property will share the same node for
mutable configs
as far as I understand it, this suggestion is addressing tomas' bullet above:
{code}
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.
{code}
i.e. you need a place to share mutable configs. It seems cleaner to have a
separate ConfigSet API, i.e. REST calls to, say, /configs/MySharedConfig rather
than to alias collection-specific APIs. The later just gets us back to the
case we are in now, where collection-specific APIs can result in changes
outside the collection. That is confusing IMO.
> Config APIs should not modify the ConfigSet
> -------------------------------------------
>
> Key: SOLR-7570
> URL: https://issues.apache.org/jira/browse/SOLR-7570
> Project: Solr
> Issue Type: Improvement
> Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-7570.patch
>
>
> Originally discussed here:
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201505.mbox/%3CCAMJgJxSXCHxDzJs5-C-pKFDEBQD6JbgxB=-xp7u143ekmgp...@mail.gmail.com%3E
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
