*Thanks for starting this thread Ben! Definitely agree that having a single project-owned Kubernetes operator for Cassandra is preferred over a fragmented ecosystem. I'll echo the same sentiment based on conversations that it appears the community is eager to share experiences and implementations in this space.Speaking for both myself and some other contributors I've been working with, we're super excited to collaborate with the community on this unified/standardized project-based operator. It seems that nobody is tied to their own code and are open to one solution that blends the best of all of these operators.Given the current virtual event way of life we are experiencing, would everyone be ok with me organizing a Zoom call for anyone who is interested so we can kick this off properly? If we all engage our social networks, I think this could be a great way of growing the community and inviting new contributors to the project. When done, I can post the notes and video in the cwiki. Patrick*
On Tue, Mar 31, 2020 at 8:09 AM Jake Luciani <j...@apache.org> wrote: > 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 > > >
