[
https://issues.apache.org/jira/browse/SOLR-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343271#comment-14343271
]
Per Steffensen commented on SOLR-7176:
--------------------------------------
I think we should not make ZkCLI a Swiss Army Knife. ZkCLI should deal with ZK
operations, like uploading and downloading. Changing then content of a
json-file is not a ZK operation. Why not see it as different things. So what
you need to do if you want to make arbitrary changes to json-content of a znode
in ZK is
{code}
zkcli getfile thefile.json
<use another tool for modifying thefile.json>
zkcli putfile thefile.json
{code}
It would be nice to make different tools that can make operations on the
different types of jsons we have in a safe way - ensuring e.g. consistency,
integrity, validity etc. But I think those tools should use the classes already
handling those jsons, and not have anything to do with ZkCLI. E.g. a tool for
manipulating clusterstate.json should use classes from
org.apache.solr.common.cloud in solrj project, like ZkStateReader, ClusterState
etc. Then it is always those classes that are used to operate on a specific
type of json, and we only have to build consistency, integrity, validity etc
into those classes (separation of concern). The new thing should be that those
classes can be used via an external tool also when no Solr nodes are running.
At least make sure to use those existing classes for actually
reading/writing/verifying the jsons, and make separate tool-classes. Changing
ZkCLI to be able to trigger operations in those tool-classes is less important,
but personally I do not like - actually, if it has to be, I would rather see
e.g. an ClusterPropCLI-tool support a "do-in-zk"-flag making it use ZkCLI tool
to download first, do its manipulations and then use ZkCLI to upload again.
That is, new tools that use ZkCLI (if you are too lazy doing the
download/upload using ZkCLI yourself), instead of the other way around, where
ZkCLI uses other tools or even just does json-manipulation itself. Please do
not try to implement rules about what can and cannot be in a specific type of
json, what operations you can do on it etc two places in the code-base - use
what we already have.
That said, maybe you can live with using e.g. http://trentm.com/json/ (or one
of the million other command-line json tools available) in <use another tool
for modifying thefile.json> above?
> allow zkcli to modify JSON
> --------------------------
>
> Key: SOLR-7176
> URL: https://issues.apache.org/jira/browse/SOLR-7176
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
> Priority: Minor
>
> To enable SSL, we have instructions like the following:
> {code}
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put
> /clusterprops.json '{"urlScheme":"https"}'
> {code}
> Overwriting the value won't work well when we have more properties to put in
> clusterprops. We should be able to change individual values or perhaps merge
> values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
