I think there is certainly an appetite to donate and standardise on a given operator (as mentioned in this thread).
I personally found the SIG hard to participate in due to time zones and the synchronous nature of it. So while it was a great forum to dive into certain details for a subset of participants and a worthwhile endeavour, I wouldn't paint it as an accurate reflection of community intent. I don't think that any participants want to continue down the path of "let a thousand flowers bloom". That's why we are looking towards CasKop (as well as a number of technical reasons). Some of the recorded meetings and outputs can also be found if you are interested in some primary sources https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG . >From what I understand second-hand from talking to people on the SIG calls, > there was a general inability to agree on an existing operator as a > starting point and not much engagement on taking best of breed from the > various to combine them. Seems to leave us in the "let a thousand flowers > bloom" stage of letting operators grow in the ecosystem and seeing which > ones meet the needs of end users before talking about adopting one into the > foundation. > > Great to hear that you folks are joining forces though! Bodes well for C* > users that are wanting to run things on k8s. > > > > On Tue, Sep 22, 2020 at 4:26 AM, Ben Bromhead <b...@instaclustr.com> wrote: > > > For what it's worth, a quick update from me: > > > > CassKop now has at least two organisations working on it substantially > > (Orange and Instaclustr) as well as the numerous other contributors. > > > > Internally we will also start pointing others towards CasKop once a few > > things get merged. While we are not yet sunsetting our operator yet, it > is > > certainly looking that way. > > > > I'd love to see the community adopt it as a starting point for working > > towards whatever level of functionality is desired. > > > > Cheers > > > > Ben > > > > On Fri, Sep 11, 2020 at 2:37 PM John Sanda <john.sa...@gmail.com> wrote: > > > > On Thu, Sep 10, 2020 at 5:27 PM Josh McKenzie <jmcken...@apache.org> > > wrote: > > > > There's basically 1 java driver in the C* ecosystem. We have 3? 4? or > > > > more > > > > operators in the ecosystem. Has one of them hit a clear supermajority of > > adoption that makes it the de facto default and makes sense to pull it > > > > into > > > > the project? > > > > We as a project community were pretty slow to move on building a PoV > > > > around > > > > kubernetes so we find ourselves in a situation with a bunch of contenders > > for inclusion in the project. It's not clear to me what heuristics we'd > > > > use > > > > to gauge which one would be the best fit for inclusion outside letting > > community adoption speak. > > > > --- > > Josh McKenzie > > > > We actually talked a good bit on the SIG call earlier today about > > heuristics. We need to document what functionality an operator should > > include at level 0, level 1, etc. We did discuss this a good bit during > > some of the initial SIG meetings, but I guess it wasn't really a focal > > point at the time. I think we should also provide references to existing > > operator projects and possibly other related projects. This would benefit > > both community users as well as people working on these projects. > > > > - John > > > > -- > > > > Ben Bromhead > > > > Instaclustr | www.instaclustr.com | @instaclustr > > <http://twitter.com/instaclustr> | (650) 284 9692 > > > -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr <http://twitter.com/instaclustr> | (650) 284 9692
