Hi, first of all I think that we should not reinvent the wheel here. I think that I am not far from the truth when I say that Orange's operator is the most mature one when it comes to features and the most battle-tested. I have not checked how it is done in details internally yet but I am satisfied that this operator is based on operator-sdk which is essentially a must as it is "industry standard". We are building our operator on operator-sdk too but we do not support multi dc yet (we have never had a need to implement it as we were adding feature as the demand was forming, this stuff is overall for a lot of folks so bleeding-edge that any cluster on k8s a business runs will do it, not thinking about multi-dc at first at all) There are some gaps in API versioning as well and I would like to know how it is done in Orange's case.
At the same time, I see that Orange's operator would like to leverage Instaclustr's backup / restore functionality as I read that from their list of checkboxes in their main readme doc. We do integrate this tooling of ours into our operator seamlessly. I believe it could serve basically as a drop-in solution more or less quite easily. I think it would be just another "command" in Orange operator terminology. I am sure there is already a plethora of excellent ideas from Datastax too and it would be nice if we put heads together. To cherry-pick the best solutions from all operators, throw some dtests on top of that and we should be golden. Regards On Wed, 1 Apr 2020 at 06:59, Patrick McFadin <pmcfa...@gmail.com> wrote: > > 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 > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
