[
https://issues.apache.org/jira/browse/SOLR-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068742#comment-15068742
]
Mike Drob commented on SOLR-8415:
---------------------------------
bq. should take a path, like CLEAN
Optional path or required path? Could still default to / if no path given, or
could make the path required for consistency. Or could accept multiple paths.
I think operating on / will be the most common use case, so it would make sense
to default to it, but I'll defer to you on this.
bq. catch NoNodeException, like CLEAN
Good catch.
bq. Will this work if the version of the znode is set?
Yea, the -1 means don't care about the version.
bq. Why don't you support retryOnConnLoss?
Not sure what this means.
bq. Would be good to test that the acls get applied recursively
The existing test does this. Set acls on /, test on /collections/collection1
bq. maybe change your test to do this (or do both this and the
secure/non-secure version, should be simple to do both probably).
I've been tinkering with a test for this, I'm having some trouble getting the
providers and credentials lines up in a way that tests something meaningful. I
think I can get it though.
> Provide command to switch between non/secure mode in ZK
> -------------------------------------------------------
>
> Key: SOLR-8415
> URL: https://issues.apache.org/jira/browse/SOLR-8415
> Project: Solr
> Issue Type: Improvement
> Components: security, SolrCloud
> Reporter: Mike Drob
> Assignee: Gregory Chanan
> Fix For: Trunk
>
> Attachments: SOLR-8415.patch, SOLR-8415.patch
>
>
> We have the ability to run both with and without zk acls, but we don't have a
> great way to switch between the two modes. Most common use case, I imagine,
> would be upgrading from an old version that did not support this to a new
> version that does, and wanting to protect all of the existing content in ZK,
> but it is conceivable that a user might want to remove ACLs as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
