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 > > > > > >
