Is there an API for
I saw there is scylladb/api/api-doc at master · scylladb/scylladb · GitHub. Is this the right place to look for APIs?
The Scylla server indeed has a REST API and it’s documentation is at the URL you point to. You can find a Swagger UI when you start the Scylla server as well: https://docs.scylladb.com/operating-scylla/rest/.
But, please note that
nodetool, for example, does not use the API directly. Instead, it talks to the Scylla JMX proxy, which is a Java process that implements Cassandra-compatible JMX API. You can still use the REST API directly, but you have to figure out the mapping between the JMX operations and the REST API yourself.
For something like
nodetool tablestats, the first step is to check what JMX APIs nodetool uses:
The command delegates to TableStatsHolder class:
which uses the ColumnFamilyStoreMBean JMX API for querying table statistics.
You can find the implementation of the JMX API in the scylla-jmx project by finding the ColumnFamilyStore class (without the MBean suffix):
From that class, you can see that, for example, the
ColumnFamilyStore.getSSTableCountPerLevel() method delegates to the
column_family/sstables/per_level/<table name> REST API URL.
Hey, thanks for the answer but i’d like to ask more. If you know, or could point me at the direction of how to divide the actual scylla and the scylla-jmx. Meaning we wanted to get rid of cassandra on hosts just because it uses java, and it’s a huge package almost 30mb in size, while our goal was to make a tiniest distro possible. Is it possible to, let’s say, start scylla on the host and jmx nodetool services in a container on the same host, so API ports are reachable from inside the container? This way we would have no need for java in the initial distro and therefore on hosts
We have not done that, but we’ll be looking at this direction in the future - makes total sense to separate them.
Thank you for the quick response. Is there an approximate date you may look in to it, maybe in your backlog? So i would know when to get back to the though of replacing cassandra again?
It’s not urgent. Besides being large and perhaps the need to update more often, it’s not a hassle. Splitting it has consequences that we’ll have to deal with. For example, running multiple containers side-by-side.
Have heard you. Thanks anyway!