Hi Ben! Totally agree. We should collaborate on a unified operator and I think as deployment on k8s becomes more and more prevalent we need to have distributed testing in k8s.
To that end we are working on OSS releasing our distributed testing service we've developed over the years to make this easier and reproducible. Need a few more days before that's ready but it may give us a leg up. I know Alex Petrov has been working a lot on the new jvm dtest harness and may have some ideas. Jake On Tue, Mar 31, 2020 at 12:11 AM Ben Bromhead <b...@instaclustr.com> wrote: > 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 >
