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/running their own or just getting started, there appears to be some broader enthusiasm to a more unified approach outside of just that thread.
The current state of play for folks looking to run Apache Cassandra, particularly on Kubernetes, is fairly fragmented. There are multiple projects all doing similar things from large companies operating C* at scale on kubernetes, individual contributors and commercialising entities. Each one of these projects also have similar but diverse implementations and capabilities. From an end user perspective, it makes it very hard to figure out what path to take and from someone who supports these end users, I'd much rather support one implementation than 3 even if it's not the one we wrote :) To that end, I'd like to indicate that we (Instaclustr) are open to working towards a project owned standardized K8s operators/sidecar/etc. How that looks and how it gets implemented will surely be the subject of debate, especially amongst those with existing implementations. Before engaging in CEP process ( https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201) it might be useful to informally discuss an approach to unifying implementations. To that end I'd like to circulate the following ideas to kick off the discussion of an approach that might be useful: We should look to start off with a new implementation in a separate repo (as the sidecar project has done), leveraging the experience and contributions from existing operator implementations and a framework like the operator-framework, with the initial scope of just supporting our distributed testing in our CI pipeline. Targeting our own distributed test cases (e.g. dtests) brings a number of benefits: - Defines a common environment and goals that minimizes each organisations unique kubernetes challenges. - Follows the spirit of the 4.0 release to be more dba/operator aligned, more production ready and easier to get right in a production setting OOB - Our test environment over time will look more and more like how users run Cassandra in production. This will be the biggest win IMHO. - The distributed tests will also serve as functional tests for the operator itself. The main drawback I can see with this approach is it will potentially be a longer path to getting a useable project based operator out the door. It will also involve a ton of reworking dtests, which for some is going to a hard blocker. From there we can start to expand and support more and more real life use cases. Hopefully this is not a huge leap as our testing should be covering most of those cases! This is largely my personal gut feel on the approach and I'm looking forward to folks other suggestions! Cheers -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr <http://twitter.com/instaclustr> | (650) 284 9692
