Sure. Let me figure out some timing and propose some times. On Tue, Mar 31, 2020 at 5:15 PM Nate McCall <zznat...@gmail.com> wrote:
> Given the large portion of work that's been done in EU by the Orange folks > vs. that of PST and APAC, I think this might be one for which we do two > versions: PST morning and evening. > > On Wed, Apr 1, 2020 at 12:51 PM Patrick McFadin <pmcfa...@gmail.com> > wrote: > > > *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 > > > > > > > > > >
