[
https://issues.apache.org/jira/browse/SOLR-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943875#comment-14943875
]
Gregory Chanan commented on SOLR-8054:
--------------------------------------
Thanks for the responses [[email protected]] and [[email protected]].
bq. Thinking about a view config API like this, I think I'd want some way to
get an individual file or all the files (as a zip, in one stream, whatever ends
up making sense) depending on param.
I think both individual file and all file APIs make sense. For the all file
APIs, I'm not sure whether as a zip or all in one stream makes more sense. Is
there an existing API where we provide multiple files in one stream? I'd
rather follow that logic than make something up myself.
{quote}
Should uploading (cloning) configsets be taken into consideration here?
{quote}
Yes, but I've tried to stay away from exposing file-modication based APIs
directly in Solr due to the security issues discussed in SOLR-5287 / SOLR-5539.
One approach to thinking about this is to break the operations into tasks a
cluster-level administrator would do vs tasks an individual would do and seeing
if we can do the later without file-based APIs.
bq. Downloading the config for the purposes of making a backup, with the
ability to restore it later after trying some different things
This falls into tasks an individual would do. An individual could do this
today via cloning their copy via the ConfigSet API and "restoring" via
deleting/copying the old one. That's not super easy, but you could provide a
nicer interface by say, keeping track of the changes with version numbers and
letting you restore from version number. So I don't think this strictly needs
a file-based API.
bq. Essentially cloning a config in a different cluster (testing,
troubleshooting, etc)
That's an interesting use case because it's sort of between what a user would
do and what an administrator would do. One possibility is to have some
higher-level cross-cluster replication functionality that lets you replicate
configs to another cluster. You could imagine this happening on all configs or
some subset. Alternatively, if the user is an administrator of the backup
cluster (which seems likely here), there is nothing stopping you from using the
existing ZkCLI commands. That's just not feasible if ZK security is on and the
user doing the operations doesn't have permissions, but that doesn't seem that
likely in this case.
{quote}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.{quote}
Yes, that's a good point. Hopefully the above makes sense -- provide Solr APIs
for end users and have administrators use the ZkCLI.
> 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: [email protected]
For additional commands, e-mail: [email protected]
