lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8054) Add a GET command to ConfigSets API
Date Mon, 05 Oct 2015 19:23:27 GMT

    [ 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 [~markrmiller@gmail.com] and [~yseeley@gmail.com].

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message