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