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

Yonik Seeley commented on SOLR-8054:
------------------------------------

Should uploading (cloning) configsets be taken into consideration here?

I'm thinking about usecases involving
 - Downloading the config for the purposes of making a backup, with the ability 
to restore it later after trying some different things
 - Essentially cloning a config in a different cluster (testing, 
troubleshooting, etc)

bq. (I hope) the future is API-based like the Config/Schema API, not File-based.

Both seem useful (If I'm correctly understanding what you mean by File-based).  
APIs may manipulate the state, but dealing with the persisted state as a whole 
also seems useful.  For instance, cloning a config via config APIs that deal 
with individual settings seems difficult.


> Add a GET command to ConfigSets API
> -----------------------------------
>
>                 Key: SOLR-8054
>                 URL: https://issues.apache.org/jira/browse/SOLR-8054
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>
> It would be useful to have a command that allows you to view a ConfigSet via 
> the API rather than going to zookeeper directly.  Mainly for security 
> reasons, e.g.
> - solr may have different security requirements than the ZNodes e.g. only 
> solr can view znodes but any authenticated user can call ConfigSet API
> - it's nicer than pointing to the web UI and using the zookeeper viewer, 
> because of the same security concerns as above and that you don't have to 
> know the internal zookeeper paths.



--
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

Reply via email to