> > I realise there are meeting logs, but getting a wider discourse with > non-stakeholder input might help to build a community consensus? It > doesn't seem like it can hurt at this point, anyway. >
+1 On Wed, Sep 23, 2020 at 9:21 PM Benedict Elliott Smith <bened...@apache.org> wrote: > Perhaps it helps to widen the field of discussion to the dev list? > > It might help if each of the stakeholder organisations state their view on > the situation, including why they would or would not support a given > approach/operator, and what (preferably specific) circumstances might lead > them to change their mind? > > I realise there are meeting logs, but getting a wider discourse with > non-stakeholder input might help to build a community consensus? It > doesn't seem like it can hurt at this point, anyway. > > > On 23/09/2020, 17:13, "John Sanda" <john.sa...@gmail.com> wrote: > > I want to point out that pretty much everything being discussed in > this > thread has been discussed at length during the SIG meetings. I think > it is > worth noting because we are pretty much still have the same > conversation. > > On Wed, Sep 23, 2020 at 12:03 PM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > I don't think there's anything about a code drop that's not "The > Apache > > Way" > > > > If there's a consensus (or even strong majority) amongst invested > parties, > > I don't see why we could not adopt an operator directly into the > project. > > > > It's possible a green field approach might lead to fewer hard > feelings, as > > everyone is in the same boat. Perhaps all operators are also > suboptimal and > > could be improved with a rewrite? But I think coordinating a lot of > > different entities around an empty codebase is particularly > challenging. I > > actually think it could be better for cohesion and collaboration to > have a > > suboptimal but substantive starting point. > > > > > > On 23/09/2020, 16:11, "Stefan Miklosovic" < > > stefan.mikloso...@instaclustr.com> wrote: > > > > I think that from Instaclustr it was stated quite clearly > multiple > > times that we are "fine to throw it away" if there is something > better > > and more wide-spread.Indeed, we have invested a lot of time in > the > > operator but it was not useless at all, we gained a lot of quite > > unique knowledge how to put all pieces together. However, I > think that > > this space is going to be quite fragmented and "balkanized", > which is > > not always a bad thing, but in a quite narrow area as Kubernetes > > operator is, I just do not see how 4 operators are going to be > > beneficial for ordinary people ("official" from community, ours, > > Datastax one and CassKop (without any significant order)). Sure, > > innovation and healthy competition is important but to what > extent ... > > One can start a Cassandra cluster on Kubernetes just so many > times > > differently and nobody really likes a vendor lock-in. People > wanting > > to run a cluster on K8S realise that there are three operators, > each > > backed by a private business entity, and the community operator > is not > > there ... Huh, interesting ... One may even start to question > what is > > wrong with these folks that it takes three companies to build > their > > own solution. > > > > Having said that, to my perception, Cassandra community just > does not > > have enough engineers nor contributors to keep 4 operators alive > at > > the same time (I wish I was wrong) so the idea of selecting the > best > > one or to merge obvious things and approaches together is > > understandable, even if it meant we eventually sunset ours. In > > addition, nobody from big players is going to contribute to the > code > > base of the other one, for obvious reasons, so channeling and > > directing this effort into something common for a community > seems to > > be the only reasonable way of cooperation. > > > > It is quite hard to bootstrap this if the donation of the code > in big > > chunks / whole repo is out of question as it is not the "Apache > way" > > (there was some thread running here about this in more depth a > while > > ago) and we basically need to start from scratch which is quite > > demotivating, we are just inventing the wheel and nobody is up > to it. > > It is like people are waiting for that to happen so they can > jump in > > "once it is the thing" but it will never materialise or at least > the > > hurdle to kick it off is unnecessarily high. Nobody is going to > invest > > in this heavily if there is already a working operator from > companies > > mentioned above. As I understood it, one reason of not choosing > the > > way of donating it all is that "the learning and community > building > > should happen in organic manner and we just can not accept the > > donation", but is not it true that it is easier to build a > community > > around something which is already there rather than trying to > build it > > around an idea which is quite hard to dedicate to? > > > > On Wed, 23 Sep 2020 at 15:28, Joshua McKenzie < > jmcken...@apache.org> > > wrote: > > > > > > > I think there's significant value to the community in trying > to > > coalesce > > > on a single approach, > > > I agree. Unfortunately in this case, the parties with a vested > > interest and > > > written operators came to the table and couldn't agree to > coalesce > > on a > > > single approach. John Sanda attempted to start an initiative to > > write a > > > best-of-breed combining choice parts of each operator, but that > > effort did > > > not gain traction. > > > > > > Which is where my hypothesis comes from that if there were a > clear > > "better > > > fit" operator to start from we wouldn't be in a deadlock; the > correct > > > choice would be obvious. Reasonably so, every engineer that's > written > > > something is going to want that something to be used and not > thrown > > away in > > > favor of another something without strong evidence as to why > that's > > the > > > better choice. > > > > > > As far as I know, nobody has made a clear case as to a more > > compelling > > > place to start in terms of an operator donation the project > then > > > collaborates on. There's no mass adoption evidence nor feature > > enumeration > > > that I know of for any of the approaches anyone's taken, so the > > discussions > > > remain stalled. > > > > > > > > > > > > On Wed, Sep 23, 2020 at 7:18 AM, Benedict Elliott Smith < > > bened...@apache.org > > > > wrote: > > > > > > > I think there's significant value to the community in trying > to > > coalesce > > > > on a single approach, earlier than later. This is an > opportunity > > to expand > > > > the number of active organisations involved directly in the > Apache > > > > Cassandra project, as well as to more quickly expand the > project's > > > > functionality into an area we consider urgent and important. > I > > think it > > > > would be a real shame to waste this opportunity. No doubt it > will > > be hard, > > > > as organisations have certain built-in investments in their > own > > approaches. > > > > > > > > I haven't participated in these calls as I do not consider > myself > > to have > > > > the relevant experience and expertise, and have other > focuses on > > the > > > > project. I just wanted to voice a vote in favour of trying to > > bring the > > > > different organisations together on a single approach if > possible. > > Is there > > > > anything the project can do to help this happen? > > > > > > > > On 23/09/2020, 03:04, "Ben Bromhead" <b...@instaclustr.com> > wrote: > > > > > > > > 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 > > > > > > > > > > > --------------------------------------------------------------------- To > > > > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For > > additional > > > > commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > > - John > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >