Hello Folks,
First of all, thank you for your comments. Your feedback motivates me
to implement these changes and refine the final result to the highest
standard. To keep the vote thread clean, I'm addressing your questions
in the discussion thread.
The vote is here:
https://lists.apache.org/thread/zmgvo2ty5nqvlz1xccsls2kcrgnbjh5v
= The idea: =
First, let me focus on the general idea, and then I will answer your
questions in more detail.
The main focus is on introducing a new API (CQL) to invoke the same
node management commands. While this has an indirect effect on tooling
(cqlsh, nodetool), the tooling itself is not the main focus. The scope
(or Phase 1) of the initial changes is narrowed down only to the API
only, to ensure the PR remains reviewable.
This implies the following:
- the nodetool commands and the way they are implemented won't change
- the nodetool commands will be accessible via CQL, their
implementation will not change (and the execution locality)
- this change introduces ONLY a new way of how management commands
will be invoked
- this change is not about the tooling (cqlsh, nodetool), it will help
them evolve, however
- these changes are being introduced as an experimental API with a
feature flag, disabled by default
= The answers: =
how will the new CQL API behave if the user does not specify a hostname?
The changes only affect the API part; improvements to the tooling will
follow later. The command is executed on the node that the client is
connected to.
Note also that the port differs from 9042 (default) as a new
management port will be introduced. See examples here [1].
cqlsh 10.20.88.164 11211 -u myusername -p mypassword
nodetool -h 10.20.88.164 -p 8081 -u myusername -pw mypassword
If a host is not specified, the cli tool will attempt to connect to
localhost. I suppose.
My understanding is that commands like nodetool bootstrap typically run on a
single node.
This is correct; however, as I don't control the implementation of the
command, it may actually involve communication with other nodes. This
is actually not part of this CEP. I'm only reusing the commands we
already have.
Will we continue requiring users to specify a hostname/port explicitly, or will
the CQL API be responsible for orchestrating the command safely across the
entire cluster or datacenter?
It seems that you are confusing the API with the tooling. The tooling
(cqlsh, nodetool) will continue to work as it does now. I am only
adding a new way in which commands can be invoked - CQL,
orchestration, however, is the subject of other projects. Cassandra
Sidecar?
It might, however, be worth verifying that the proposed CQL syntax aligns with
PostgreSQL conventions, and adjusting it if needed for cross-compatibility.
It's a bit new info to me that we're targeting PostgreSQL as the main
reference and drifting towards the invoking management operations the
same way. I'm inclined to agree that the syntax should probably be
similar, more or less, however.
We are introducing a new CQL syntax in a minimal and isolated manner.
The CEP-38 defines a small set of management-oriented CQL statements
(EXECUTE COMMAND / DESCRIBE COMMAND) that can be used to match all
existing nodetool commands at once, introducing further aliases as an
option. This eliminates the need to introduce a new antlr grammar for
each management operation.
The command execution syntax is the main thing that users interact
with in this CEP, but I'm taking a more relaxed approach to it for the
following reasons:
- the tip of the iceberg, the unification of the JMX, CQL and possible
REST API for Cassandra is priority;
- the feature will be in experimental state in the major release, we
need collect the real feedback from users and their deployments;
- the aliasing will be used for some important commands like
compaction, bootstrap;
Taking all of the above into account, I still think it's important to
reach an agreement, or at least to avoid objections.
So, I've checked the PostgreSQL and SQL standards to identify areas of
alignment. The latter I think is relatively easy to support as
aliases.
The syntax proposed in the CEP:
EXECUTE COMMAND forcecompact WITH keyspace=distributed_test_keyspace
AND table=tbl AND keys=["k4", "k2", "k7"];
Other Cassandra-style options that I had previously considered:
1. EXECUTE COMMAND forcecompact (keyspace=distributed_test_keyspace,
table=tbl, keys=["k4", "k2", "k7"]);
2. EXECUTE COMMAND forcecompact WITH ARGS {"keyspace":
"distributed_test_keyspace", "table": "tbl", "keys":["k4", "k2",
"k7"]};
With the postgresql context [2] it could look like:
COMPACT (keys=["k4", "k2", "k7"]) distributed_test_keyspace.tbl;
The SQL-standard [3][4] procedural approach:
CALL system_mgmt.forcecompact(
keyspace => 'distributed_test_keyspace',
table => 'tbl',
keys => ['k4','k2','k7'],
options => { "parallel": 2, "verbose": true }
);
Please let me know if you have any questions, or if you would like us
to arrange a call to discuss all the details.
[1]https://www.instaclustr.com/support/documentation/cassandra/using-cassandra/connect-to-cassandra-with-cqlsh/
[2]https://www.postgresql.org/docs/current/sql-vacuum.html
[3]https://en.wikipedia.org/wiki/Stored_procedure?utm_source=chatgpt.com#Implementation
[4]https://www.postgresql.org/docs/9.3/functions-admin.html
