Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <1640443672.14181264193422723.JavaMail.jira@brutus.apache.org>
Date: Fri, 22 Jan 2010 20:50:22 +0000 (UTC)
From: "Robert Coli (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Commented: (CASSANDRA-698) ClusterProbe
In-Reply-To: <209322085.229411263431814440.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803861#action_12803861 ] 

Robert Coli commented on CASSANDRA-698:
---------------------------------------

First off, very happy to see "clusterprobe" style functionality for those cases (get_endpoints! yay!) where you really do want to ask a question to the entire cluster.  :D

As to the division of functionality into "clusterprobe" vs "nodeprobe", I have a proposed solution which would seem to result in extended nodeprobe functionality without creating much new user-facing complexity. 

Make "clusterprobe" the top level tool and have it take --node=[node1,node2,...,nodeXX] as an argument. This would allow you to both query the entire cluster  and query a subset or the nodeprobe case of a single node. Even something like "get_endpoints" might be useful on a subset nodelist, if you do not actually want to ask the entire cluster. This interface also avoids questions of the format "which tool should this new feature go in" or "which tool has this feature", and the possibility of duplicating code which could be used in either/both contexts. If a user specifies a nodelist in the context of a cluster-wide-only operation, syntax erroring out should be simple. In the case of "nodeprobe"-like questions with a nodelist, it'd just produce the answer for each node in the list, possibly including a builtin way to make the nodelist "all nodes"?

I clearly do not know how or how well the implementation of this would work with the existing code, but as an ops-centric "interested party", I thought I would suggest the idea, FWIW!

> ClusterProbe
> ------------
>
>                 Key: CASSANDRA-698
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-698
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Tools
>            Reporter: Chris Goffinet
>            Assignee: Eric Evans
>            Priority: Minor
>             Fix For: 0.6
>
>         Attachments: 0001-Added-ClusterProbe.-Supports-get_endpoints-key.patch, v3-0001-CASSANDRA-698-NodeProbe-refactor-move-main-to-new-clas.txt, v3-0002-NodeProbe-refactor-move-print-methods-to-new-class.txt, v3-0003-add-new-getEndPoints-method.txt, v3-0004-add-clustercmd-tool-currently-only-prints-endpoints.txt
>
>
> I'd like to introduce ClusterProbe, for situations where you want to find information at cluster level. The first operation is get_endpoints, where you can supply a key. I want to also add support for showing hit ratio for column families at cluster level.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.