Kurt Greaves commented on CASSANDRA-7622:

bq. I'm not really sure a lot of ops people would even notice this new feature 
as long as we don't pull the plug on JMX.
New users would still likely use it over JMX because it would hopefully be more 
user friendly (JMX is pretty ugly). If we could make it perform better than JMX 
that would be a big win (this seems unlikely though). Once people implement the 
tools to gather metrics from it the cost to users for crossing over to the 
vTables would be pretty minimal.

There's no reason to only expose config in cqlsh. Ops people would want to do 
reading and writing to config properties from their own programs, and limiting 
it to cqlsh would be nasty. Being able to use CQL would be ideal for config 

On another note I can think of a couple examples for "replicated vTables" such 
as whole cluster state. At the moment if you want to do any proper monitoring 
on cluster state (down nodes) you have to aggregate all this information 
yourself from every node in the cluster. With replicated vTables we could 
easily store cluster state in a table and update it, making monitoring much 
easier for everyone. This also goes for things like repairs, where we could 
better expose repairs happening across the cluster, nodes, and ranges involved. 
We could probably even use it to better manage repairs that fail (e.g 
automatically kill off validations that are no longer important).

Being able to read and modify config I'd still say is the biggest win however.

> Implement virtual tables
> ------------------------
>                 Key: CASSANDRA-7622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Tupshin Harper
>            Assignee: Jeff Jirsa
>            Priority: Major
>             Fix For: 4.x
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to