Re: 4-26-2020 update on Kubernetes Operator

[Deepak Vohra]

 I have added a potential Goal to CEP-2:Deploying and managing Kubernetes 
resources depends a lot on the Cloud Service provider used. Is it a goal to 
target  integration with any/all/some Cloud Service providers???

On Monday, April 27, 2020, 04:33:45 p.m. UTC, Stefan Miklosovic 
 wrote:  
 
 Hi Deepak,

while we would be delighted to take Instaclustr's operator as a
baseline, this is not so simple ...

I think we should gather all functional requirements first, improve
and complete the actual CEP and based on these facts we should distil
the best solution, whatever it would be.

In general, I do not want this whole operator effort to be about "ours
or theirs" and "who wins", it should be done _together_. My take on
this as of now is that let's forget about all operators and let's
pretend we just want to build a new one. Based on what operator we
want to have, after that we will look around and make some comparison
to see what is already available among all operators out there. Based
on that, we could cherry-pick features and approaches from each or
introduce some completely different and only after that we would start
to think about the implementation. I think we are just at the very
beginning and I do not think that mentioning whatever operator at this
moment is a good idea (but I am glad you are interested!).

How does this sound to you? Do you think that you could be helpful
with going through the CEP Patrick has compiled while adding more
details and features you would like to see? That would be of
tremendous help and we would know more in detail what we actually want
and we can discuss it in more detail afterwards.

Regards and thanks a lot in advance

On Mon, 27 Apr 2020 at 17:16, Deepak Vohra  wrote:
>
>  An operator for Apache Cassandra in alpha is provided by Instaclustr that 
>supports StatefulSet, scaling and monitoring. Could it be used as the base 
>operator to build on? OperatorHub.io | The registry for Kubernetes Operators
>
> |
> |
> |  |
> OperatorHub.io | The registry for Kubernetes Operators
>
> The registry for Kubernetes Operators
>  |
>
>  |
>
>  |
>
>
>
>
>
>    On Monday, April 27, 2020, 05:49:37 a.m. UTC, Patrick McFadin 
> wrote:
>
>  *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: Google Season of Docs 2020 participation

[Deepak Vohra]

 It may be early, but  considering  first an organization has to apply, and as 
I am familiar with what sections of documentation could be improved, I have a 
few suggestions. Only two projects (1 and 2 of 5 listed) were completed in 
2019, and GSoD expects only one project to be completed. Projects 3 and 4 
listed are projects listed in 2019 also but not selected and these would be 
suitable as projects to complete in 2020. I have added a fifth project about 
version 4.0  improvements. 
1. Apache Cassandra 4.0 Documentation Update 
2.  Resolve TODOs in Apache Cassandra Documentation 
3. Improving CQL DocumentationApache Cassandra is a distributed database that 
is seeking a qualified technical writer to create documentation for Cassandra's 
Query Language (CQL). CQL, like SQL, is a query language that allows users to 
interact with Cassandra. Similarly, CQL provides syntactic structures such as 
DDL (Data Definition Language), DML (Data Modification Language) and DCL (Data 
Control Language). CQL also has well defined grammar and syntax which may vary 
with the Cassandra version. While Apache Cassandra 4.0 will be the newest 
version, the documentation should also provide support for the earlier versions 
of Cassandra 2.x, 3.x, and 3.11.x. There are approximately 40 CQL commands, 
with several options available for each. The document should contain example 
usages for each CQL command, as well as how its use varies amongst the 
different versions. This could theoretically cover also some core schema design 
principles and best practices, as well as how to design tables in order to 
achieve optimal performance and usability.
4.  Detailed Nodetool Documentation for Operators  Apache Cassandra is a 
distributed database that is seeking a qualified technical writer to create 
documentation for Cassandra's nodetool. nodetool is a command line tool which 
Cassandra operators will often use for their day-to-day operations. It is one 
of the mechanisms by which an operator interacts with a node in the cluster. 
Therefore, it is a critical aspect of building and managing a Cassandra 
cluster. This documentation should support Cassandra 2.x, 3.x, 3.11.x, 4.x. 
There are approximately 80 nodetool commands, with several options available 
for each. The document should also contain examples for each nodetool command, 
as well as how it varies amongst the different versions. It would be very nice 
to have not only the "how" behind a particular command, but also "why" these 
commands would be used. The operator should know what each command is for and 
under which circumstances one should use them. It may be useful for the 
commands to be grouped by category (ex: commands for grouping SSTables, et al). 
There could also be some definition around frequent scenarios and workflows to 
highlight using various nodetool commands to identify, debug and resolve issues 
within a Cassandra cluster, in terms of every-day usage.
5. Improvements in Apache Cassandra 4.0. 
thanks,Deepak

On Monday, April 27, 2020, 10:37:08 p.m. UTC, Dinesh Joshi 
 wrote:  
 
 Folks,

GSoD 2020 is upon us. The organizational applications are due soon May 4th 2020 
and I'd like us to participate in it again. GSoD 2019 brought in great deal of 
improvements to the C* docs and I believe GSoD 2020 will be able to bring in 
more enhancements. I realize we are also talking about docs donations from 
DataStax but the docs project can be focused on 4.0 which would not overlap 
with the donation. If you have opinions, please let me know.

Cheers,

Dinesh
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
  

Google Season of Docs 2020 participation

[Dinesh Joshi]

Folks,

GSoD 2020 is upon us. The organizational applications are due soon May 4th 2020 
and I'd like us to participate in it again. GSoD 2019 brought in great deal of 
improvements to the C* docs and I believe GSoD 2020 will be able to bring in 
more enhancements. I realize we are also talking about docs donations from 
DataStax but the docs project can be focused on 4.0 which would not overlap 
with the donation. If you have opinions, please let me know.

Cheers,

Dinesh
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: DataStax Driver Donation to Apache Cassandra Project

[Nate McCall]

Thanks, Stephen, this is really helpful!

On Tue, Apr 28, 2020 at 6:24 AM Stephen Mallette 
wrote:

> >
> > To step out of the weeds a bit - other than the Zookeeper / Curator
> > example, does anyone know of any other apache projects that have either
> > subprojects or complementary sideprojects they're interdependent upon in
> > their ecosystems?
>
>
> Every Apache project is different, so it's quite possible that the
> experience I have in this area doesn't apply much here, but I'll offer some
> words on the matter in the event that some of it is helpful.
>
> For many years even prior to joining Apache, TinkerPop was quite against
> bringing in driver-style sub-projects. Our main concern was one that I
> think was voiced here in this thread in some fashion, where core developers
> would have to be knowledgeable of the incoming body of work and maintain
> that going forward. For core contributors who were primarily Java
> developers it was difficult to think that we'd suddenly be responsible for
> reviews/VOTEs on Python code, for example.  It was with a bit of
> trepidation that we eventually decided it a good idea and opened the
> project to them. For our purposes we brought all such projects directly
> into our core repository as the thinking was that we wanted to keep all
> aspects of the project unified (testing, release, etc) to ensure that for a
> particular release tag you could be sure that everything worked together.
> We initially started with just Python and developed that as our model for
> how new drivers would arrive (there were already other disparate projects
> out there in other languages).
>
> We wanted a model that ensured a reasonably high bar for acceptance and
> created a rough set of minimum criteria we wanted to have for adding a new
> driver to our release lines. The core of that criteria was a common
> language agnostic test suite that needed to pass for us to consider it
> "ready" in any sense and the project needed to build, test and release
> using Maven (which is our build tool for the project). The former ensured
> that we had a reasonable level of common tested functionality among drivers
> and the latter ensured an easy and consistent way to manage build/release
> practices (which fed nicely into our Docker infrastructure for both full
> builds and for giving non-JVM developers a nice way to develop drivers
> against the latest code without having to be Java experts). Once we
> established this approach with Python, we successfully brought in .NET and
> Javascript.
>
> I think there were a number of nice upsides to deciding to bring in drivers
> in the first place and then in the model for acceptance that we chose:
>
> + We saw a greater diversity of folks contributing in general as the
> ecosystem opened up beyond just the JVM.
> + We saw that the general community coalesced around the "official"
> drivers, contributing as one to them, rather than going off and creating
> one-off projects. I'm not really aware of any third-party drivers right now
> for the languages we support, but if you look at something like Go, there
> are three or more choices. I suppose Go would be our next target for
> official inclusion.
> + Release day was pretty simple despite the complexity of the environment
> with that mixed ecosystem because of our unified build model using Maven
> and there wasn't a lot of disparate tooling exposed to the release manager
> directly.
> + I can't say that we really saw problems with core project developers (who
> mostly new Java) having to review python/c#/javascript. For the most part,
> the contribution quality was high and we managed and became more
> knowledgeable as we went.
> + As we released drivers and core together, we no longer had situations
> where some third-party driver lagged behind some feature in core - if you
> wanted to use the latest core functionality you just used the latest
> release of core and driver and you could be assured they worked together
> and we felt confident saying so.
>
> Doing it over again, I think I would still consider going single repo for
> this situation but I think I might not place the requirement that the
> projects build with Maven. I think Maven has turned-off some contributors
> from those language ecosystems who don't know the JVM. They would have been
> much more comfortable just working more directly with the tool systems that
> they were familiar with. Of course, to get rid of local maven builds
> completely we would have to build a "latest" Docker images so that folks
> didn't need to do that themselves like they do now (also with Maven).
>
> Aside from TinkerPop experiences I will offer that, while I'm not
> completely sure, I think that for a contribution like this one where the
> bulk of the code has been developed outside of the ASF, the DS drivers
> would need to go through an IP Clearance process:
>
> https://incubator.apache.org/ip-clearance/
>
>
>
> On Mon, Apr 27, 2020 at 12:57 PM Joshua 

Re: DataStax Driver Donation to Apache Cassandra Project

[Stephen Mallette]

>
> To step out of the weeds a bit - other than the Zookeeper / Curator
> example, does anyone know of any other apache projects that have either
> subprojects or complementary sideprojects they're interdependent upon in
> their ecosystems?


Every Apache project is different, so it's quite possible that the
experience I have in this area doesn't apply much here, but I'll offer some
words on the matter in the event that some of it is helpful.

For many years even prior to joining Apache, TinkerPop was quite against
bringing in driver-style sub-projects. Our main concern was one that I
think was voiced here in this thread in some fashion, where core developers
would have to be knowledgeable of the incoming body of work and maintain
that going forward. For core contributors who were primarily Java
developers it was difficult to think that we'd suddenly be responsible for
reviews/VOTEs on Python code, for example.  It was with a bit of
trepidation that we eventually decided it a good idea and opened the
project to them. For our purposes we brought all such projects directly
into our core repository as the thinking was that we wanted to keep all
aspects of the project unified (testing, release, etc) to ensure that for a
particular release tag you could be sure that everything worked together.
We initially started with just Python and developed that as our model for
how new drivers would arrive (there were already other disparate projects
out there in other languages).

We wanted a model that ensured a reasonably high bar for acceptance and
created a rough set of minimum criteria we wanted to have for adding a new
driver to our release lines. The core of that criteria was a common
language agnostic test suite that needed to pass for us to consider it
"ready" in any sense and the project needed to build, test and release
using Maven (which is our build tool for the project). The former ensured
that we had a reasonable level of common tested functionality among drivers
and the latter ensured an easy and consistent way to manage build/release
practices (which fed nicely into our Docker infrastructure for both full
builds and for giving non-JVM developers a nice way to develop drivers
against the latest code without having to be Java experts). Once we
established this approach with Python, we successfully brought in .NET and
Javascript.

I think there were a number of nice upsides to deciding to bring in drivers
in the first place and then in the model for acceptance that we chose:

+ We saw a greater diversity of folks contributing in general as the
ecosystem opened up beyond just the JVM.
+ We saw that the general community coalesced around the "official"
drivers, contributing as one to them, rather than going off and creating
one-off projects. I'm not really aware of any third-party drivers right now
for the languages we support, but if you look at something like Go, there
are three or more choices. I suppose Go would be our next target for
official inclusion.
+ Release day was pretty simple despite the complexity of the environment
with that mixed ecosystem because of our unified build model using Maven
and there wasn't a lot of disparate tooling exposed to the release manager
directly.
+ I can't say that we really saw problems with core project developers (who
mostly new Java) having to review python/c#/javascript. For the most part,
the contribution quality was high and we managed and became more
knowledgeable as we went.
+ As we released drivers and core together, we no longer had situations
where some third-party driver lagged behind some feature in core - if you
wanted to use the latest core functionality you just used the latest
release of core and driver and you could be assured they worked together
and we felt confident saying so.

Doing it over again, I think I would still consider going single repo for
this situation but I think I might not place the requirement that the
projects build with Maven. I think Maven has turned-off some contributors
from those language ecosystems who don't know the JVM. They would have been
much more comfortable just working more directly with the tool systems that
they were familiar with. Of course, to get rid of local maven builds
completely we would have to build a "latest" Docker images so that folks
didn't need to do that themselves like they do now (also with Maven).

Aside from TinkerPop experiences I will offer that, while I'm not
completely sure, I think that for a contribution like this one where the
bulk of the code has been developed outside of the ASF, the DS drivers
would need to go through an IP Clearance process:

https://incubator.apache.org/ip-clearance/



On Mon, Apr 27, 2020 at 12:57 PM Joshua McKenzie 
wrote:

> To step out of the weeds a bit - other than the Zookeeper / Curator
> example, does anyone know of any other apache projects that have either
> subprojects or complementary sideprojects they're interdependent upon in
> their ecosystems? I'd 

Re: DataStax Driver Donation to Apache Cassandra Project

[Jon Haddad]

Separate JIRA is enough enough, separate dev list.. maybe.  I don't see
much purpose in trying to organize into a hierarchy, what problem are you
actually solving here?  It sounds like you don't trust folks who work on
the driver to not commit random code to Cassandra, is that the case?  If
that's not a concern, I don't know what we gain by a hierarchy other than
complexity.

Every committer doesn't have to work on every part of the project, nor be
aware of the daily activity.


On Mon, Apr 27, 2020 at 10:03 AM Benedict Elliott Smith 
wrote:

> +1, this is essentially my position, and I agree with the baseline
> requirements for a merged project.  I'm not trying to rule anything out,
> just wondering what the optimal division is.
>
> I think from the user point of view we can hopefully achieve the same
> appearance with or without the same project governance.  The goal should
> absolutely be to have "official" drivers, and close association.  We can
> link them directly in the Cassandra site either way.  The question is only
> how the projects are best structured.
>
> It seems to me that drivers benefit from an umbrella structure for their
> governance and for discussing their commonalities and direction, but also
> need their own distinct lists and Jira.  So we'd be talking about going
> from a flat hierarchy to perhaps a three-tier structure, something like:
>
>PMC
> /   \
> Drivers Cassandra
>  /   |   \   \
> Driver1  Dvr.2   Dvr.3 ...Sidecar?
>
> Since drivers are functionally very different to the database server and
> its accoutrements, there will likely be very different kinds of
> discussions, with completely different release schedules - hopefully mostly
> around programmatic API UX, client-side performance, etc.  It feels to me
> intuitively like there is benefit in keeping distinct the projects with
> different focuses and technical problems, so that discussions more easily
> can happen simultaneously at the design and decision-making levels.
>
> This might not only help avoid fragmentation of the decision-making in
> this community, but also help unify decision-making across the drivers.  By
> having a decision-making body whose purview is only drivers, we might
> better emphasise collaboration between those drivers, since that is the
> body's only function.
>
> I'm not staking this out as a strongly held prior conviction, just that I
> see these problems and think we have to consider this carefully upfront, as
> I don't think this kind of decision is easy to revisit.
>
>
>
> On 27/04/2020, 10:51, "Sylvain Lebresne"  wrote:
>
> Fwiw, I agree with the concerns raised by Benedict, and think we should
> carefully think about how this is handled. Which isn't not a rejection
> of
> the donation in any way.
>
> Drivers are not small projects, and the majority of their day to day
> maintenance is unrelated to the server (and the reverse is true).
>
> From the user point of view, I think it would be fabulous that
> Cassandra
> appears like one project with a server and some official drivers, with
> one
> coherent website and documentation for all. I'm all for striving for
> that.
>
> Behind the scenes however, I feel tings should be setup so that some
> amount
> of
> separation remains between server and whichever drivers are donated and
> accepted, or I'm fairly sure things would get messy very quickly[1]).
> In my
> mind that means *at a minimum*:
> - separate JIRA projects.
> - dedicated _dev_ (and commits) mailing lists.
>
> But it's also worth thinking whether a single pool of committers/PMC
> members is
> desirable.
>
> Tbc, I'm not sure what is the best way to achieve this within the
> constraint of
> the Apache fundation, and maybe I'm just stating the obvious here.
>
>
> [1] fwiw, I say this as someone that at some points in time was
> simultaneously
> somewhat actively involved in both Cassandra and the DataStax Java
> driver.
>
> --
> Sylvain
>
>
> On Fri, Apr 24, 2020 at 12:54 AM Benedict Elliott Smith <
> bened...@apache.org>
> 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 - 

Re: DataStax Driver Donation to Apache Cassandra Project

[Benedict Elliott Smith]

+1, this is essentially my position, and I agree with the baseline requirements 
for a merged project.  I'm not trying to rule anything out, just wondering what 
the optimal division is.

I think from the user point of view we can hopefully achieve the same 
appearance with or without the same project governance.  The goal should 
absolutely be to have "official" drivers, and close association.  We can link 
them directly in the Cassandra site either way.  The question is only how the 
projects are best structured.

It seems to me that drivers benefit from an umbrella structure for their 
governance and for discussing their commonalities and direction, but also need 
their own distinct lists and Jira.  So we'd be talking about going from a flat 
hierarchy to perhaps a three-tier structure, something like:

   PMC
/   \
Drivers Cassandra
 /   |   \   \
Driver1  Dvr.2   Dvr.3 ...Sidecar?

Since drivers are functionally very different to the database server and its 
accoutrements, there will likely be very different kinds of discussions, with 
completely different release schedules - hopefully mostly around programmatic 
API UX, client-side performance, etc.  It feels to me intuitively like there is 
benefit in keeping distinct the projects with different focuses and technical 
problems, so that discussions more easily can happen simultaneously at the 
design and decision-making levels.  

This might not only help avoid fragmentation of the decision-making in this 
community, but also help unify decision-making across the drivers.  By having a 
decision-making body whose purview is only drivers, we might better emphasise 
collaboration between those drivers, since that is the body's only function. 

I'm not staking this out as a strongly held prior conviction, just that I see 
these problems and think we have to consider this carefully upfront, as I don't 
think this kind of decision is easy to revisit.



On 27/04/2020, 10:51, "Sylvain Lebresne"  wrote:

Fwiw, I agree with the concerns raised by Benedict, and think we should
carefully think about how this is handled. Which isn't not a rejection of
the donation in any way.

Drivers are not small projects, and the majority of their day to day
maintenance is unrelated to the server (and the reverse is true).

From the user point of view, I think it would be fabulous that Cassandra
appears like one project with a server and some official drivers, with one
coherent website and documentation for all. I'm all for striving for that.

Behind the scenes however, I feel tings should be setup so that some amount
of
separation remains between server and whichever drivers are donated and
accepted, or I'm fairly sure things would get messy very quickly[1]). In my
mind that means *at a minimum*:
- separate JIRA projects.
- dedicated _dev_ (and commits) mailing lists.

But it's also worth thinking whether a single pool of committers/PMC
members is
desirable.

Tbc, I'm not sure what is the best way to achieve this within the
constraint of
the Apache fundation, and maybe I'm just stating the obvious here.


[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.

--
Sylvain


On Fri, Apr 24, 2020 at 12:54 AM 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 

Re: DataStax Driver Donation to Apache Cassandra Project

[Joshua McKenzie]

To step out of the weeds a bit - other than the Zookeeper / Curator
example, does anyone know of any other apache projects that have either
subprojects or complementary sideprojects they're interdependent upon in
their ecosystems? I'd like to reach out to some other pmc's for advice and
feedback on this topic since there's no sense in reinventing the wheel if
other projects have wisdom to share on this.

On Mon, Apr 27, 2020 at 12:42 PM Joshua McKenzie 
wrote:

> re: ML noise, how hard would it be to filter out JIRA updates w/component
> "Drivers"? Or from JIRA queries?
>
> For governance, I see it cutting both ways. If we have two separate
> projects and ML's for drivers and C*, how do we keep a coherent view of new
> features and roadmap stuff? Do we have CEP's for both projects and tie them
> together? Do we drive changes in the driver feature ecosystem via CEP's in
> C*?
>
> In the Venn diagram of overlap vs. non between the two projects, I see
> there being more overlap than not.
>
> On Mon, Apr 27, 2020 at 12:34 PM Dinesh Joshi  wrote:
>
>>
>>
>> > On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne 
>> wrote:
>> >
>> > Fwiw, I agree with the concerns raised by Benedict, and think we should
>> > carefully think about how this is handled. Which isn't not a rejection
>> of
>> > the donation in any way.
>> >
>> > Drivers are not small projects, and the majority of their day to day
>> > maintenance is unrelated to the server (and the reverse is true).
>> >
>> > From the user point of view, I think it would be fabulous that Cassandra
>> > appears like one project with a server and some official drivers, with
>> one
>> > coherent website and documentation for all. I'm all for striving for
>> that.
>>
>> +1
>>
>> > Behind the scenes however, I feel tings should be setup so that some
>> amount
>> > of
>> > separation remains between server and whichever drivers are donated and
>> > accepted, or I'm fairly sure things would get messy very quickly[1]).
>> In my
>>
>> Can you say more about what "getting messy very quickly" means here?
>>
>> > mind that means *at a minimum*:
>> > - separate JIRA projects.
>> > - dedicated _dev_ (and commits) mailing lists.
>>
>> If we're thinking through how this would be setup, initially we had the
>> same Jira project for sidecar but now there is a separate one to track
>> sidecar specific jiras. At the moment we do not have a separate mailing
>> list. I think Cassandra dev mailing list's volume is low enough to keep
>> using the same ML. There is an added value that it gives visibility and
>> developers don't need to go between multiple mailing lists.
>>
>> > But it's also worth thinking whether a single pool of committers/PMC
>> > members is
>> > desirable.
>> >
>> > Tbc, I'm not sure what is the best way to achieve this within the
>> > constraint of
>> > the Apache fundation, and maybe I'm just stating the obvious here.
>> >
>> >
>> > [1] fwiw, I say this as someone that at some points in time was
>> > simultaneously
>> > somewhat actively involved in both Cassandra and the DataStax Java
>> driver.
>> >
>> > --
>> > Sylvain
>> >
>> >
>> > On Fri, Apr 24, 2020 at 12:54 AM Benedict Elliott Smith <
>> bened...@apache.org>
>> > 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 

Re: DataStax Driver Donation to Apache Cassandra Project

[Joshua McKenzie]

re: ML noise, how hard would it be to filter out JIRA updates w/component
"Drivers"? Or from JIRA queries?

For governance, I see it cutting both ways. If we have two separate
projects and ML's for drivers and C*, how do we keep a coherent view of new
features and roadmap stuff? Do we have CEP's for both projects and tie them
together? Do we drive changes in the driver feature ecosystem via CEP's in
C*?

In the Venn diagram of overlap vs. non between the two projects, I see
there being more overlap than not.

On Mon, Apr 27, 2020 at 12:34 PM Dinesh Joshi  wrote:

>
>
> > On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne 
> wrote:
> >
> > Fwiw, I agree with the concerns raised by Benedict, and think we should
> > carefully think about how this is handled. Which isn't not a rejection of
> > the donation in any way.
> >
> > Drivers are not small projects, and the majority of their day to day
> > maintenance is unrelated to the server (and the reverse is true).
> >
> > From the user point of view, I think it would be fabulous that Cassandra
> > appears like one project with a server and some official drivers, with
> one
> > coherent website and documentation for all. I'm all for striving for
> that.
>
> +1
>
> > Behind the scenes however, I feel tings should be setup so that some
> amount
> > of
> > separation remains between server and whichever drivers are donated and
> > accepted, or I'm fairly sure things would get messy very quickly[1]). In
> my
>
> Can you say more about what "getting messy very quickly" means here?
>
> > mind that means *at a minimum*:
> > - separate JIRA projects.
> > - dedicated _dev_ (and commits) mailing lists.
>
> If we're thinking through how this would be setup, initially we had the
> same Jira project for sidecar but now there is a separate one to track
> sidecar specific jiras. At the moment we do not have a separate mailing
> list. I think Cassandra dev mailing list's volume is low enough to keep
> using the same ML. There is an added value that it gives visibility and
> developers don't need to go between multiple mailing lists.
>
> > But it's also worth thinking whether a single pool of committers/PMC
> > members is
> > desirable.
> >
> > Tbc, I'm not sure what is the best way to achieve this within the
> > constraint of
> > the Apache fundation, and maybe I'm just stating the obvious here.
> >
> >
> > [1] fwiw, I say this as someone that at some points in time was
> > simultaneously
> > somewhat actively involved in both Cassandra and the DataStax Java
> driver.
> >
> > --
> > Sylvain
> >
> >
> > On Fri, Apr 24, 2020 at 12:54 AM Benedict Elliott Smith <
> bened...@apache.org>
> > 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:
> >>
> >>

Re: DataStax Driver Donation to Apache Cassandra Project

[Dinesh Joshi]

> On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne  wrote:
> 
> Fwiw, I agree with the concerns raised by Benedict, and think we should
> carefully think about how this is handled. Which isn't not a rejection of
> the donation in any way.
> 
> Drivers are not small projects, and the majority of their day to day
> maintenance is unrelated to the server (and the reverse is true).
> 
> From the user point of view, I think it would be fabulous that Cassandra
> appears like one project with a server and some official drivers, with one
> coherent website and documentation for all. I'm all for striving for that.

+1

> Behind the scenes however, I feel tings should be setup so that some amount
> of
> separation remains between server and whichever drivers are donated and
> accepted, or I'm fairly sure things would get messy very quickly[1]). In my

Can you say more about what "getting messy very quickly" means here?

> mind that means *at a minimum*:
> - separate JIRA projects.
> - dedicated _dev_ (and commits) mailing lists.

If we're thinking through how this would be setup, initially we had the same 
Jira project for sidecar but now there is a separate one to track sidecar 
specific jiras. At the moment we do not have a separate mailing list. I think 
Cassandra dev mailing list's volume is low enough to keep using the same ML. 
There is an added value that it gives visibility and developers don't need to 
go between multiple mailing lists.

> But it's also worth thinking whether a single pool of committers/PMC
> members is
> desirable.
> 
> Tbc, I'm not sure what is the best way to achieve this within the
> constraint of
> the Apache fundation, and maybe I'm just stating the obvious here.
> 
> 
> [1] fwiw, I say this as someone that at some points in time was
> simultaneously
> somewhat actively involved in both Cassandra and the DataStax Java driver.
> 
> --
> Sylvain
> 
> 
> On Fri, Apr 24, 2020 at 12:54 AM 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 

Re: 4-26-2020 update on Kubernetes Operator

[Stefan Miklosovic]

Hi Deepak,

while we would be delighted to take Instaclustr's operator as a
baseline, this is not so simple ...

I think we should gather all functional requirements first, improve
and complete the actual CEP and based on these facts we should distil
the best solution, whatever it would be.

In general, I do not want this whole operator effort to be about "ours
or theirs" and "who wins", it should be done _together_. My take on
this as of now is that let's forget about all operators and let's
pretend we just want to build a new one. Based on what operator we
want to have, after that we will look around and make some comparison
to see what is already available among all operators out there. Based
on that, we could cherry-pick features and approaches from each or
introduce some completely different and only after that we would start
to think about the implementation. I think we are just at the very
beginning and I do not think that mentioning whatever operator at this
moment is a good idea (but I am glad you are interested!).

How does this sound to you? Do you think that you could be helpful
with going through the CEP Patrick has compiled while adding more
details and features you would like to see? That would be of
tremendous help and we would know more in detail what we actually want
and we can discuss it in more detail afterwards.

Regards and thanks a lot in advance

On Mon, 27 Apr 2020 at 17:16, Deepak Vohra  wrote:
>
>  An operator for Apache Cassandra in alpha is provided by Instaclustr that 
> supports StatefulSet, scaling and monitoring. Could it be used as the base 
> operator to build on? OperatorHub.io | The registry for Kubernetes Operators
>
> |
> |
> |  |
> OperatorHub.io | The registry for Kubernetes Operators
>
> The registry for Kubernetes Operators
>  |
>
>  |
>
>  |
>
>
>
>
>
> On Monday, April 27, 2020, 05:49:37 a.m. UTC, Patrick McFadin 
>  wrote:
>
>  *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*

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: 4-26-2020 update on Kubernetes Operator

[Eric Evans]

On Mon, Apr 27, 2020 at 2:30 AM Dinesh Joshi  wrote:

> Hi Patrick,
>
> Thanks for driving the meetings. It would be good to have the on going
> discussions on the dev list for people in time zones that cannot attend the
> meetings in real time.
>

+1

I would never (try to) tell anyone that they cannot teleconference with
like-minded peers, but it feels worth mentioning that this format will
never be totally inclusive.



> > On Apr 26, 2020, at 10:49 PM, Patrick McFadin 
> wrote:
> >
> > *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
> > <
> 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
> > <
> 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
> > <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-2+Kubernetes+Operator
> >
> > 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
> > <
> 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
> > <
> https://github.com/operator-framework/operator-sdk/blob/master/doc/operator-capabilities.md
> >.
> > 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*
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Eric Evans (he/him)
Senior Software Engineer, Core Platform
Wikimedia Foundation
eev...@wikimedia.org

Re: 4-26-2020 update on Kubernetes Operator

[Deepak Vohra]

 An operator for Apache Cassandra in alpha is provided by Instaclustr that 
supports StatefulSet, scaling and monitoring. Could it be used as the base 
operator to build on? OperatorHub.io | The registry for Kubernetes Operators

| 
| 
|  | 
OperatorHub.io | The registry for Kubernetes Operators

The registry for Kubernetes Operators
 |

 |

 |





On Monday, April 27, 2020, 05:49:37 a.m. UTC, Patrick McFadin 
 wrote:  
 
 *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

[Sylvain Lebresne]

Fwiw, I agree with the concerns raised by Benedict, and think we should
carefully think about how this is handled. Which isn't not a rejection of
the donation in any way.

Drivers are not small projects, and the majority of their day to day
maintenance is unrelated to the server (and the reverse is true).

>From the user point of view, I think it would be fabulous that Cassandra
appears like one project with a server and some official drivers, with one
coherent website and documentation for all. I'm all for striving for that.

Behind the scenes however, I feel tings should be setup so that some amount
of
separation remains between server and whichever drivers are donated and
accepted, or I'm fairly sure things would get messy very quickly[1]). In my
mind that means *at a minimum*:
- separate JIRA projects.
- dedicated _dev_ (and commits) mailing lists.

But it's also worth thinking whether a single pool of committers/PMC
members is
desirable.

Tbc, I'm not sure what is the best way to achieve this within the
constraint of
the Apache fundation, and maybe I'm just stating the obvious here.


[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.

--
Sylvain


On Fri, Apr 24, 2020 at 12:54 AM 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 commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: DataStax Driver Donation to Apache Cassandra Project

[Mick Semb Wever]

> > - 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.


Currently there are 36 servers, all Ubuntu. What can't be tested with
docker (ie mac and windows) would need additional servers donated.


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


Maybe start gathering and writing up the PROs and CONs for each
approach in a separate doc.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: 4-26-2020 update on Kubernetes Operator

[Dinesh Joshi]

Hi Patrick,

Thanks for driving the meetings. It would be good to have the on going 
discussions on the dev list for people in time zones that cannot attend the 
meetings in real time.

Dinesh

> On Apr 26, 2020, at 10:49 PM, Patrick McFadin  wrote:
> 
> *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*


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org