4-26-2020 update on Kubernetes Operator

[Patrick McFadin]

*Hi everyone,Over the past two weeks, we have had 4 public meetings with a
lot of great discussions. You can find the recordings and notes here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG
There
were some important next steps after this week. First is some housekeeping.
Having two meetings allowed for better time zone spread, but the
discussions were disconnected and tended to be somewhat redundant. It was
suggested to move to a single meeting that can span the most timezones. I
took that feedback and have rebuilt the SIG meeting schedules in the same
type of rotation being used for the Contributor Meetings. We’ll see how
that goes for everyone effected. I’ve also switched away from Zoom to Jitsi
(jitsi.org ). Switching to a more open video conferencing
software seemed like a natural move and the feature list is comparable to
Zoom.All the meeting details and schedule are posted here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG
This
includes a calendar file and shared calendar link. Next important thing is
the beginning of the CEP for the Kubernetes Operator. Ben Bromhead and I
took a first pass at a skeleton for CEP-2

with all the basics. At this point, we need everyone participating in the
project to take some time and help build out some of the critical details.
Because everyone loves Confluence so much, I have created a Google doc we
can use as a working area before moving over to a more formal Cassandra
Wiki.
https://docs.google.com/document/d/18Ow4R3tB9GIvdcFO7WmUvjb0a-sT6h0zSCEnfHsPz58/edit?usp=sharing
Everyone
has edit rights. Please use the comment functionality if you have questions
about a particular section.The main portion that really needs the most
thoughtful work is Operator Capability Level
.
What does each level mean in Cassandra terms. There was already some good
debate about configuration and common tasks like repair. Let’s get that
captured in the doc if we can. If you are one of the groups that already
have an operator, your experience here is invaluable. Please take some time
of you can. Thanks and looking forward to the collaboration. Patrick*

Re: DataStax Driver Donation to Apache Cassandra Project

[Adam Holmberg]

Thanks for the early input here.

> - Which major branch of the Java driver should be chosen for development?
> > -- Server currently uses Java driver 3.x but the latest is 4.x
>
> No opinions here. What are the major differences here? Could you please
> elaborate.
>
4.x is our actively developed branch. It was a major release with some
breaking changes:
https://www.datastax.com/blog/2019/03/introducing-java-driver-4

> - How will we run CI for these contributions?
>
> ASF Jenkins/CircleCI works? Do the drivers have specific needs beyond this?
>
 That will probably work. I asked partially because the driver CI can have
a fairly extensive matrix of platforms, runtimes, and server versions. I'm
not sure how much excess capacity the current Jenkins pool has.

How should we proceed deciding sub-project vs. incubator question discussed
here?

Adam

On Sat, Apr 25, 2020 at 3:42 PM Dinesh Joshi  wrote:

> Benedict,
>
> Your concerns are valid and its great to think through issues that might
> occur in the future. I personally have never thought that the driver should
> be treated as a separate entity because as a user, Cassandra cannot be used
> _without_ a driver. Drivers are the public interface and are tightly
> coupled with the server. I personally feel that we should take the donation
> as part of the Cassandra project and if we see issues we try to resolve
> them at that point.
>
> Thanks,
>
> Dinesh
>
> > On Apr 23, 2020, at 3:54 PM, Benedict Elliott Smith 
> wrote:
> >
> > Do you have some examples of issues?
> >
> > So, to explain my thinking: I believe there is value in most
> contributors being able to know and understand a majority of what the
> project undertakes.  Many people track a wide variety of activity on the
> project, and whether they express an opinion they probably form one and
> will involve themselves if they consider it important to do so.  I worry
> that importing several distinct and only loosely related projects to the
> same governance and communication structures has a strong potential to
> undermine that capability, as people begin to assume that activity and
> decision-making is unrelated to them - and if that happens I think
> something important is lost.
> >
> > The sidecar challenges this already but seems hopefully manageable: it
> is a logical extension of Cassandra, existing primarily to plug gaps in
> Cassandra's own functionality, and features may migrate to Cassandra over
> time.  It is likely to have releases closely tied to Cassandra itself.
> Other subprojects are so far exclusively for consumption by the Cassandra
> project itself, and are all naturally coupled.
> >
> > Drivers however are inherently arms-length endeavours: we publish a
> protocol specification, and driver maintainers implement it.  They are
> otherwise fairly independent, and while a dialogue is helpful it does
> > not need to be controlled by a single entity.  Many drivers will
> continue to be controlled by others, as they have been until now.  We're of
> course able to ensure there's a strong overlap of governance, which I think
> would be very helpful, and something Curator and Zookeeper seem not to have
> managed.
> >
> > Looking at the Curator website, it also seems to pitch itself as a
> relatively opinionated product, and much more than a driver.  I hope the
> recipe for conflict in our case is much more limited given the functional
> scope of a driver - and anyway better avoided with more integrated, but
> still distinct governance.
> >
> > That's not to say I don't see some value in the project controlling the
> driver directly, I just worry about the above.
> >
> >
> >
> > On 22/04/2020, 21:25, "Nate McCall"  wrote:
> >
> >On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith <
> bened...@apache.org>
> >wrote:
> >
> >> I welcome the donation, and hope we are able to accept all of the
> >> drivers.  This is really great news IMO.
> >>
> >> I do however wonder if the project may be accumulating too many
> >> sub-projects?  I wonder if it's time to think about splitting, and
> perhaps
> >> incubating a project for the drivers?
> >>
> >
> >This is a legit concern and good question, but I think this is more a
> >natural evolution of growing a project. There is precedent for this in
> >Spark, Beam, Hadoop and others who have a number of different
> repositories
> >under the general project umbrella.
> >
> >What I would like to avoid is a situation like with Apache Curator and
> >Apache Zookeeper. The former being a zookeeper client donation from
> Netflix
> >that came in as a top level project. From the peanut gallery, it
> seems like
> >that has been less than ideal a couple of times in the past
> coordinating
> >releases, trademarks and such with separate project management.
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional c