[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315845#comment-15315845
]
Robert Stupp commented on CASSANDRA-7622:
-----------------------------------------
Don't get me wrong, I really like virtual tables, but I am not a fan of a
{{CREATE TABLE}} for metrics - instead, I think it is better to provide
predefined, virtual tables for what we have in a "virtual keyspace" like
{{system_metrics}} or {{system_management}}. Some administrative operations
probably require additional CQL commands (e.g. {{ALTER SYSTEM DRAIN;}}).
Also, pushing notifications and alerts via the native protocol would be really
nice.
If we move metrics from JMX and management to CQL, which could be a legit
long-term goal IMO, the native-protocol must *always* be available - at least,
there must be some "backdoor" that allows access to metrics+management. A
virtual table statement like {{UPDATE system_management.native_protocol SET
enable=false}} is the C* equivalent of {{pkill -9 sshd}} - not good. There are
valid reasons to disable client access while a node is running. Another way to
lock yourself out is having expired certificates (should not occur, but does -
i'm sure).
Additionally, if we have virtual tables, gathering information from the whole
cluster, a DC or just a single node would ease a lot of administrative tasks.
E.g. {{SELECT seed_nodes FROM system_metrics.config WHERE dc='DC_eu' AND
rack='RAC_b'}} or {{ALTER SYSTEM SET enable_native_protocol = true WHERE
dc=...}}. Gathering current repair status of the whole cluster using a single
SELECT feels nice.
That's probably too much to put into a single ticket. Just wanted to leave my
thoughts.
> 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
> Fix For: 3.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
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
