I would like to propose a hybrid a hybrid of what Benedict mentioned.
Let's postpone today's (Sept 24) SIG to the next week, Oct 1. Same time.
I'll keep the same zoom with some modifications. Each group, CassKop and
cass-operator can have time to present the following:
- State your view of the situation
- Why they would or would not support a given approach/operator. Be
technically specific.
- What technical circumstances might lead them to change their mind
- Your view of a path forward
Each group will get 20 minutes with 10 minutes of q&a. I can moderate.
After the meeting I'll post the video as well as a full transcript (Thank
you Otter.ai!) If there were presentation decks, then post a PDF of those.
I'll kick off the discussion in the dev ML and we can debate here.
This is my proposal for moving things forward if possible. +1, -1 or more
debating?
Patrick
On Wed, Sep 23, 2020 at 12: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
>
>
