Hey, good stuff!
We in Instaclustr are already doing the effort in that area. We needed Sidecar (1) for our Kubernetes Cassandra operator (2) and it runs as a process in a container in the same pod where Cassandra runs. Right now it provides a very simple API how operations are invoked against that. There are two options, either via JMX or it is possible to leverage CQL connection. These operations are called from REST interface and we provide simple operations API on top of that (operation submission, getting its status and so on). In practice it is possible to use this Sidecar as as a standalone application which just connects to whatever Cassandra it is pointed to but it can also live in Kubernetes as already mentioned where it takes its credentials from pluggable Cassandra driver configuration mechanism from Kubernetes secrets / config maps (2) if custom auth is required. I can clearly see that we have a lot of sidecar implementations going on which is always good! It would be nice to exchange experiences and approaches taken and distil it ideally into one sidecar which would be the flagship of sidecars once and for all! Regards (1) https://github.com/instaclustr/cassandra-operator/tree/master/java/sidecar (2) https://github.com/instaclustr/cassandra-operator (3) https://github.com/instaclustr/cassandra-operator/blob/master/doc/auth.md#ssl-with-sidecar On Mon, 30 Mar 2020 at 17:20, Jake Luciani <j...@apache.org> wrote: > > Hello! > As discussed on the contributors call a couple weeks back[1], I'd like to > announce the open sourcing of a Management API Sidecar project for Apache > Cassandra that some of us have been using at Datastax[2]. It is separate > from the existing C* sidecar subproject right now as we needed specific > functionality to support an operator that we're actively open-sourcing as > well. The intent is to work on incorporating this with the official C* > sidecar project[3]. > > I'll cover the core similarities/differences I see below: > > Similarities: > * Simple REST API for operations > * Healthchecks > * Lifecycle management > * Basic configuration management > Differences: > * Local access only. > - Each sidecar process is responsible for the local C* instance > * CQL communication only. > - Communication between Management API and C* is via CQL only > - A simple CQL -> method mechanism is added to C* resulting in the > ability to execute statements like: "CALL NodeOps.compact('keyspace');" > * Secure by default. > - The Management API talks to C* via a local unix socket. > - The Management API has its own local unix socket so local tools can > communicate securely. > - Optional Mutual TLS support for secure services > - Disables default cassandra/cassandra superuser > * No configuration file > - Keeps deployments simple > * Hooks into Existing C* releases by utilizing a new java agent. > > I've opened an EPIC[4] to discuss details of this work. Sending a note > here so people are aware; I know everyone is heads down on the C* 4.0 scope > right now. > > [1]: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-1+Online+meeting+2020-03-10 > [2]: http://github.com/datastax/management-api-for-apache-cassandra > [3]: https://github.com/apache/cassandra-sidecar > [4]: https://issues.apache.org/jira/browse/CASSANDRASC-13 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
