Hi All
With the announcement of a C* Sidecar and K8s operator from Datastax
(congrats btw), Jake and Stefan discussed moving to a more
standardised/unified implementation of an Apache Cassandra operator for
Kubernetes. Based on discussions with other folks either using our
operator, building/runni
Hi Stefan!
Yes, this is exactly why we want to move things into the official sidecar.
I think the same should happen for an official k8s operator too...
If you look at the readme for the management api you'll see we are dealing
with the same issues.
The management api is PID 1 for the container a
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 t
Regardless of how we indicate optional vs. required for rel, are there
strong opinions on who should set that metadata on tickets? Reporter?
Assignee? One person? A group of people?
On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie
wrote:
> FWIW, I don't care what we go with as long as we can di
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
