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

Reply via email to