Re: Creating a branch for 5.0 …?

[Dinesh Joshi]

> On Sep 10, 2020, at 2:10 PM, Joshua McKenzie  wrote:
> 
> I can offer my anecdata: I know of two major enterprises as well as have
> had two interviewees unsolicited bring up to me that they have walked away
> from or bounced off the project due to the feature freeze / branching
> strategy. I may be the anomaly given the volume of people in the ecosystem
> I interact with, but I assume it's more than just the ones I've seen.

Did these folks bring this issue up with dev@ or private@ before deciding to go 
in a different direction?

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

Re: Creating a branch for 5.0 …?

[Jeff Jirsa]

> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith  
> wrote:
> 
> 
>> 
>> As I understand Sankalp's primary (and quite reasonable) argument the last 
>> time we discussed this
> 
> The more significant cost to the project is distracting contributors focused 
> on 4.0.  The project is bandwidth constrained right now.  Feature development 
> doesn't happen in a vacuum, and some of that bandwidth will have to go to 
> participating in any new feature development.  So, if feature development 
> begins in earnest, the 4.0 ship date will slip - by how much, who knows?
> 
> Of course, the new features will also get less attention than they should.  
> So it's a lose-lose in that respect.
> 
> I think if we are to consider this, any ticket or project for 5.0 should be 
> subject to a consensus vote before work begins.  Work that a contributor - 
> focused on the more urgent and less rewarding job of shipping 4.0 - would 
> participate in can be deferred.  Uncontentious work, or work where all 
> relevant contributors are free to participate, can make progress.

I have no opinion on branching, but I think we all know it’s not reasonable to 
say what people can and can’t work on in any open source project. PMC members 
and committers get an opinion on what goes in the repo, but not what gets 
worked on or reviewed by other committers. 
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[John Sanda]

On Thu, Sep 10, 2020 at 5:27 PM Josh McKenzie  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

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[John Sanda]

On Thu, Sep 10, 2020 at 10:58 AM  wrote:

> Hi,
>
> Thanks John for your efforts in setting up the repo and in the SIG
> meetings in general :)
>
> As the team already in charge for CasKop, we did not participate in the
> code in your repo for different reasons:
> - we never said we would. We discussed the CRD in the SIG meetings and our
> objective was to check whether CassKop’s choice were good or not, and they
> were good most of the times.
> - we were finishing V1 of CassKop with backup and restore functionalities.
> This is almost done, we are merging it as I am writing this.
> - we want to offer CassKop to the community when V1 is released as working
> code if it wants it. I mentioned this a few times in the videos so this is
> no news.
>

Thanks Franck, and I totally understand about the lack of participation in
my prototype~ish repo. I figured it was a long shot at best to get any
involvement. I felt like I needed to try something to move things forward.
If nothing else, I learned more about kustomize which I have put to good
use in some other work ;-)

- John

Re: Creating a branch for 5.0 …?

[Mick Semb Wever]

Replies inline, though I think Josh answered everything well enough already.

> The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere);
> > is just upon those that wish to take it on
>
>
> I don't follow.  If a bug fix goes into 4.0 do we not need to sync this
> with 5.0, if so then this would be the 5th branch to keep in-sync, and if
> the feature freeze is lifted then this branch may diverge making it harder
> to apply the patch to.
>


We are talking about things that would only go into a 5.0 branch.
As soon as the feature freeze is lifted, then all the commits in the 5.0
branch are rolled onto trunk (i.e. a fast-forward merge).

The branch is regularly rebased off trunk. That work is on those willing to
take on the endeavour, not the community.


Tickets that have been reviewed and are (aside from the feature-freeze)
> > ready to be committed, can be committed to the `cassandra-5.0` branch
>
>
> Is there such a backlog of tickets that have been reviewed and not going
> into 4.0.0?  What I see are ideas and things punted from review, so it
> would be good to see what this backlog is and how large.
>


You're correct, we are talking about a backlog of tickets that has not
materialised. We have enough signals to know why they are not
materialising. We can't say what will materialise, hopefully folk will come
back.  That's why we can't ask for "the backlog" in advance.

My main fear is reviews of new tickets.  A complaint I have heard multiple
> times from several people is that not enough people are reviewing and
> reviews take a long time (number of reviewers is small and their backlog
> keeps growing).



Absolutely agree with you David. Lack of reviewers, and focusing reviewers
on 4.0, is crucial. I'm pretty sure everyone agrees.
But new contributions is community health and growth, and there's genuine
concerns we're losing them. And we *are* seeing it.



> To me GH fork is the same as not committed and not reviewed.  If a fork
> would help the community then I am ok with it, but I don't see it as ready
> to commit.
>


The feature freeze is about what can and can't go into trunk (and us not
branching yet cassandra-4.0).

There's no restrictions around reviewing tickets and transitioning or
commenting them as "ready to commit" on the presumption the reviewer is one
of those bearing the burden of the cassandra-5.0 branch maintenance and
ensuring the fast-forward merge of it to a post-4.0 trunk is of the same
standard expected of every commit pushed.

If the community wanted to extend the feature freeze to blocking jira
transitions to "ready to commit" for post-4.0 work, those reviewers could
just do that book-keeping themselves. No community vote or consensus is
required for those willing to do this, because it can be done externally.
So I'm thinking going into such process formalities distracts us from
having the real conversation… who's willing to do it? and if you are, do
you believe you can do so without taking any (review) time away from 4.0
efforts? and is it clearly understood that your additional effort is
restricted to contributions from new significant contributors that we feel
we would otherwise lose?

I know folk will have strong opinions on this, that's no surprise, it's
meant as a discussion opener.

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> As I understand Sankalp's primary (and quite reasonable) argument the last 
> time we discussed this

The more significant cost to the project is distracting contributors focused on 
4.0.  The project is bandwidth constrained right now.  Feature development 
doesn't happen in a vacuum, and some of that bandwidth will have to go to 
participating in any new feature development.  So, if feature development 
begins in earnest, the 4.0 ship date will slip - by how much, who knows?

Of course, the new features will also get less attention than they should.  So 
it's a lose-lose in that respect.

I think if we are to consider this, any ticket or project for 5.0 should be 
subject to a consensus vote before work begins.  Work that a contributor - 
focused on the more urgent and less rewarding job of shipping 4.0 - would 
participate in can be deferred.  Uncontentious work, or work where all relevant 
contributors are free to participate, can make progress.


On 10/09/2020, 22:10, "Joshua McKenzie"  wrote:

I can offer my anecdata: I know of two major enterprises as well as have
had two interviewees unsolicited bring up to me that they have walked away
from or bounced off the project due to the feature freeze / branching
strategy. I may be the anomaly given the volume of people in the ecosystem
I interact with, but I assume it's more than just the ones I've seen.

Mick, correct me if I'm wrong but the merge path for a bugfix to 2.1 that
applies up to 4.0, as an example, would look like:

2.1 → 3.0 → 3.11 → trunk

With no extra work required and an accumulation of a backlog of things on
trunk not on the cassandra-5.0 branch.

If someone else were working on something in the cassandra-5.0 branch,
they'd need to rebase/rerere the 5.0 branch on trunk before making whatever
changes. In effect this would move the burden from merge resolution to
whomever was choosing to work on the cassandra-5.0 branch instead of
maintainers working on 4.0.

> Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?
Chicken or egg debate right? Nobody is going to review code for post 4.0
right now if there's nowhere to put it since it'll just atrophy and need
constant rebasing and thus re-review. Or it ends up in a fork somewhere.

As I understand Sankalp's primary (and quite reasonable) argument the last
time we discussed this, the concern was the extra work needed to merge
forward for people working on 4.0. A cassandra-5.0 branch in-tree where the
burden of maintenance would fall on people using the branch seems to
mitigate that concern.

Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?




On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith  wrote:

> We know we are turning away more and more contributions
>
> Do we? I haven't been aware of much of this occurring at all.
>
> On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:
>
> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon 
those
> that wish to take it on, and the branch can be located in whatever GH fork
> those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
> - who would be willing to help maintain this cassandra-5.0 branch?
> - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>
> - 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

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Josh McKenzie]

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


Sent via Superhuman 


On Thu, Sep 10, 2020 at 10:58 AM,  wrote:

> Hi,
>
> Thanks John for your efforts in setting up the repo and in the SIG
> meetings in general :)
>
> As the team already in charge for CasKop, we did not participate in the
> code in your repo for different reasons:
> - we never said we would. We discussed the CRD in the SIG meetings and our
> objective was to check whether CassKop’s choice were good or not, and they
> were good most of the times.
> - we were finishing V1 of CassKop with backup and restore functionalities.
> This is almost done, we are merging it as I am writing this.
> - we want to offer CassKop to the community when V1 is released as working
> code if it wants it. I mentioned this a few times in the videos so this is
> no news.
>
> An operator is a big work, don’t underestimate it!
>
> We believe not starting from scratch is better but this is only our
> opinion. Should I go formal on this offer and have a dedicated thread as
> was done for the drivers?
>
> Sincerely hope this helps
> Franck
> Product Owner of CassKop @ Orange
> https://github.com/Orange-OpenSource/casskop
> (Yes we’ll fix the vulnerability once the big merge is done :) )
>
> On 10 Sep 2020, at 05:10, John Sanda  wrote:
>
> Hey everyone,
>
> A while back I started https://github.com/jsanda/cassandra-operator in an
> effort to move things forward. One of my primary goals was to get some
> people contributing. That did not happen, which is understandable. I am
> going to throw out some questions and would love to get feedback,
> particularly from people who have been participating in the SIG and/or are
> involved with relevant projects.
>
> * Should we continue down the path of trying to build a common operator
> project? If yes, how should we proceed?
>
> * Should we broaden the focus to using and running Cassandra in Kubernetes
> in general? CEP 2 Kubernetes Operator
>  CEP-2+Kubernetes+Operator> says
> that its motivation is to make it easy to run Cassandra on Kubernetes.
> Having an operator is definitely a big part of that, but it is not the only
> part. There are important areas like application development, data
> migration, multi-region / multi-cloud clusters, and tooling integration to
> name a few. I think that the community benefits from collaboration
> regardless of whether or not there is a common operator. That is not to
> suggest that a common operator would not be good. I do not necessarily see
> it as a zero sum game where it has to be a common operator or nothing.
>
> Thanks
>
> - John
>
> _
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation. If you have received this email in
> error, please notify the sender and delete this message and its
> attachments. As emails may be altered, Orange is not liable for messages
> that have been modified, changed or falsified. Thank you.
>

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

I can offer my anecdata: I know of two major enterprises as well as have
had two interviewees unsolicited bring up to me that they have walked away
from or bounced off the project due to the feature freeze / branching
strategy. I may be the anomaly given the volume of people in the ecosystem
I interact with, but I assume it's more than just the ones I've seen.

Mick, correct me if I'm wrong but the merge path for a bugfix to 2.1 that
applies up to 4.0, as an example, would look like:

2.1 → 3.0 → 3.11 → trunk

With no extra work required and an accumulation of a backlog of things on
trunk not on the cassandra-5.0 branch.

If someone else were working on something in the cassandra-5.0 branch,
they'd need to rebase/rerere the 5.0 branch on trunk before making whatever
changes. In effect this would move the burden from merge resolution to
whomever was choosing to work on the cassandra-5.0 branch instead of
maintainers working on 4.0.

> Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?
Chicken or egg debate right? Nobody is going to review code for post 4.0
right now if there's nowhere to put it since it'll just atrophy and need
constant rebasing and thus re-review. Or it ends up in a fork somewhere.

As I understand Sankalp's primary (and quite reasonable) argument the last
time we discussed this, the concern was the extra work needed to merge
forward for people working on 4.0. A cassandra-5.0 branch in-tree where the
burden of maintenance would fall on people using the branch seems to
mitigate that concern.

Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?




On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith  wrote:

> We know we are turning away more and more contributions
>
> Do we? I haven't been aware of much of this occurring at all.
>
> On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:
>
> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
> that wish to take it on, and the branch can be located in whatever GH fork
> those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
> - who would be willing to help maintain this cassandra-5.0 branch?
> - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>
> - To
> unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional
> commands, e-mail: dev-h...@cassandra.apache.org
>

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> We know we are turning away more and more contributions

Do we? I haven't been aware of much of this occurring at all. 

On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:

We know we are turning away more and more contributions and new potential
dev community with our 4.0 feature freeze, and it has been going on for a
while now.

I would like to suggest we create a cassandra-5.0 branch where we can start
to queue up all reviewed and ready-to-go post-4.0 commits.

This is not to distract from getting 4.0 out, where our primary focus is,
but as a stop-gap in losing those contributions. The effort of the
cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
that wish to take it on, and the branch can be located in whatever GH
fork those
individuals wish to keep it in. Tickets that have been reviewed and are
(aside from the feature-freeze) ready to be committed, can be committed to
the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
status. The goal of this effort would be, a) we are giving the signal to
contributors to get involved again (even while our primary focus in on
stabilisation and testing efforts), and b) maintaining CI status on the
sequence of commits that are ready to go into trunk post 4.0-rc.

My questions are…
 - who would be willing to help maintain this cassandra-5.0 branch?
 - should it be kept external in a GH fork? Or would you rather have the
branch in our main git repository?

regards,
Mick



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

Re: Creating a branch for 5.0 …?

[David Capwell]

>
> The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere);
> is just upon those that wish to take it on


I don't follow.  If a bug fix goes into 4.0 do we not need to sync this
with 5.0, if so then this would be the 5th branch to keep in-sync, and if
the feature freeze is lifted then this branch may diverge making it harder
to apply the patch to.

Tickets that have been reviewed and are (aside from the feature-freeze)
> ready to be committed, can be committed to the `cassandra-5.0` branch


Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?  What I see are ideas and things punted from review, so it
would be good to see what this backlog is and how large.

My main fear is reviews of new tickets.  A complaint I have heard multiple
times from several people is that not enough people are reviewing and
reviews take a long time (number of reviewers is small and their backlog
keeps growing).  If we open up reviews for non 4.0.0 work then my fear is
that even less review time will be allocated to 4.0.0 work.

- who would be willing to help maintain this cassandra-5.0 branch?


I do not have the time so I will not be able to help with 5.0 work.

 - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?


To me GH fork is the same as not committed and not reviewed.  If a fork
would help the community then I am ok with it, but I don't see it as ready
to commit.

On Thu, Sep 10, 2020 at 12:58 PM Mick Semb Wever  wrote:

> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can start
> to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
> that wish to take it on, and the branch can be located in whatever GH
> fork those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
>  - who would be willing to help maintain this cassandra-5.0 branch?
>  - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>

Notification of analysis on publicly available project data

[Griselda Cuevas]

Dear PMC,


I’m contacting you because your project has been selected by the ASF D
committee which is leading a research project to evaluate and understand
the current state of diversity in our community [1]. As part of this
research, we will analyze publicly available data about your project such
as Git logs, Jira boards and mailing lists, to better understand the state
of diversity in Apache projects and to complement the findings we obtained
from the Community Survey that was run this year [2].


This analysis will be performed by Bitegia [3], a vendor specializing in
researching open source projects and foundations. The results will be
published in a report similar to the OpenStack Foundation Analysis
published in 2018 [4].


The analysis will be done only on aggregated data at the project level during
and after processing, ensuring we do not report anything that could
identify a single individual. The data we analyze will be deleted right
after the research is done and won’t be retained by either the researcher
or the ASF.


If you have any concerns or questions, please raise them to the diversity
committee (d...@diversity.apache.org) and/or to the data privacy committee (
priv...@apache.org).


Regards,

Griselda Cuevas

V.P. of Diversity and Inclusion

Apache Software Foundation


[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405614

[2] https://youtu.be/4Mr1CRtKqUI

[3] https://bitergia.com/bitergia-analytics/

[4] https://superuser.openstack.org/articles/2018-gender-diversity-report/

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[franck.dehay]

Sorry forgot to mention that we finished the backup/restore with the help of 
Instaclustr! Sorry guys!

> On 10 Sep 2020, at 16:58, DEHAY Franck DTSI/DSI  
> wrote:
> 
> Hi,
> 
> Thanks John for your efforts in setting up the repo and in the SIG meetings 
> in general :)
> 
> As the team already in charge for CasKop, we did not participate in the code 
> in your repo for different reasons:
> - we never said we would. We discussed the CRD in the SIG meetings and our 
> objective was to check whether CassKop’s choice were good or not, and they 
> were good most of the times.
> - we were finishing V1 of CassKop with backup and restore functionalities. 
> This is almost done, we are merging it as I am writing this.
> - we want to offer CassKop to the community when V1 is released as working 
> code if it wants it. I mentioned this a few times in the videos so this is no 
> news.
> 
> An operator is a big work, don’t underestimate it!
> 
> We believe not starting from scratch is better but this is only our opinion.
> Should I go formal on this offer and have a dedicated thread as was done for 
> the drivers?
> 
> Sincerely hope this helps
> Franck
> Product Owner of CassKop @ Orange
> https://github.com/Orange-OpenSource/casskop
> (Yes we’ll fix the vulnerability once the big merge is done :) )
> 
>> On 10 Sep 2020, at 05:10, John Sanda  wrote:
>> 
>> Hey everyone,
>> 
>> A while back I started https://github.com/jsanda/cassandra-operator in an
>> effort to move things forward. One of my primary goals was to get some
>> people contributing. That did not happen, which is understandable. I am
>> going to throw out some questions and would love to get feedback,
>> particularly from people who have been participating in the SIG and/or are
>> involved with relevant projects.
>> 
>> * Should we continue down the path of trying to build a common operator
>> project? If yes, how should we proceed?
>> 
>> * Should we broaden the focus to using and running Cassandra in Kubernetes
>> in general? CEP 2 Kubernetes Operator
>> 
>> says
>> that its motivation is to make it easy to run Cassandra on Kubernetes.
>> Having an operator is definitely a big part of that, but it is not the only
>> part. There are important areas like application development, data
>> migration, multi-region / multi-cloud clusters, and tooling integration to
>> name a few. I think that the community benefits from collaboration
>> regardless of whether or not there is a common operator. That is not to
>> suggest that a common operator would not be good. I do not necessarily see
>> it as a zero sum game where it has to be a common operator or nothing.
>> 
>> Thanks
>> 
>> - John
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[franck.dehay]

Hi,

Thanks John for your efforts in setting up the repo and in the SIG meetings in 
general :)

As the team already in charge for CasKop, we did not participate in the code in 
your repo for different reasons:
- we never said we would. We discussed the CRD in the SIG meetings and our 
objective was to check whether CassKop’s choice were good or not, and they were 
good most of the times.
- we were finishing V1 of CassKop with backup and restore functionalities. This 
is almost done, we are merging it as I am writing this.
- we want to offer CassKop to the community when V1 is released as working code 
if it wants it. I mentioned this a few times in the videos so this is no news.

An operator is a big work, don’t underestimate it!

We believe not starting from scratch is better but this is only our opinion.
Should I go formal on this offer and have a dedicated thread as was done for 
the drivers?

Sincerely hope this helps
Franck
Product Owner of CassKop @ Orange
https://github.com/Orange-OpenSource/casskop
(Yes we’ll fix the vulnerability once the big merge is done :) )

> On 10 Sep 2020, at 05:10, John Sanda  wrote:
> 
> Hey everyone,
> 
> A while back I started https://github.com/jsanda/cassandra-operator in an
> effort to move things forward. One of my primary goals was to get some
> people contributing. That did not happen, which is understandable. I am
> going to throw out some questions and would love to get feedback,
> particularly from people who have been participating in the SIG and/or are
> involved with relevant projects.
> 
> * Should we continue down the path of trying to build a common operator
> project? If yes, how should we proceed?
> 
> * Should we broaden the focus to using and running Cassandra in Kubernetes
> in general? CEP 2 Kubernetes Operator
> 
> says
> that its motivation is to make it easy to run Cassandra on Kubernetes.
> Having an operator is definitely a big part of that, but it is not the only
> part. There are important areas like application development, data
> migration, multi-region / multi-cloud clusters, and tooling integration to
> name a few. I think that the community benefits from collaboration
> regardless of whether or not there is a common operator. That is not to
> suggest that a common operator would not be good. I do not necessarily see
> it as a zero sum game where it has to be a common operator or nothing.
> 
> Thanks
> 
> - John


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Tolbert, Andy]

Hi John,

Thank you for your efforts on getting this bootstrapped!  I have been
meaning to try getting involved for months and appreciate that the SIG
has been recording sessions and taking down notes.

> * Should we continue down the path of trying to build a common operator
> project? If yes, how should we proceed?

I definitely think there is a lot of value having a common operator
project. The path to contributing to an operator will be much clearer
for some if it's an Apache project.

I see on your email back from Aug 5 that you mentioned a goal of:

> Ramp up a project that can eventually be considered for adoption within ASF, 
> presumably as a subproject of Cassandra

Does there need to be much code established before it gets fully
proposed as a subproject and brought under the apache organization?
>From what I recall cassandra-sidecar [1] was established as an apache
project before there was a lot of code written.

I'll be looking to provide feedback to the repository you've set up
soon, and hope I can contribute to getting this accepted as a
subproject in any way that I can.

> * Should we broaden the focus to using and running Cassandra in Kubernetes
> in general?

Not everyone running Cassandra in K8S is using an operator, so that
could be a good idea.  I'm curious if that would increase
participation, but it does seem like there is a large enough
classification of issues/improvements specific to running Cassandra on
Kubernetes that they'd be worth discussing in the SIG.

[1]: https://github.com/apache/cassandra-sidecar

Thanks,
Andy

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

Re: [DISCUSS] CEP-7 Storage Attached Index

[Jasonstack Zhao Yang]

Thank you Patrick for hosting Cassandra Contributor Meeting for CEP-7 SAI.

The recorded video is available here:
https://cwiki.apache.org/confluence/display/CASSANDRA/2020-09-01+Apache+Cassandra+Contributor+Meeting

On Tue, 1 Sep 2020 at 14:34, Jasonstack Zhao Yang 
wrote:

> Thank you, Charles and Patrick
>
> On Tue, 1 Sep 2020 at 04:56, Charles Cao  wrote:
>
>> Thank you, Patrick!
>>
>> On Mon, Aug 31, 2020 at 12:59 PM Patrick McFadin 
>> wrote:
>> >
>> > I just moved it to 8AM for this meeting to better accommodate APAC.
>> Please
>> > see the update here:
>> >
>> https://cwiki.apache.org/confluence/display/CASSANDRA/2020-08-01+Apache+Cassandra+Contributor+Meeting
>> >
>> > Patrick
>> >
>> > On Mon, Aug 31, 2020 at 10:04 AM Charles Cao 
>> wrote:
>> >
>> > > Patrick,
>> > >
>> > > 11AM PST is a bad time for the people in the APAC timezone. Can we
>> > > move it to 7 or 8AM PST in the morning to accommodate their needs ?
>> > >
>> > > ~Charles
>> > >
>> > > On Fri, Aug 28, 2020 at 4:37 PM Patrick McFadin 
>> > > wrote:
>> > > >
>> > > > Meeting scheduled.
>> > > >
>> > >
>> https://cwiki.apache.org/confluence/display/CASSANDRA/2020-08-01+Apache+Cassandra+Contributor+Meeting
>> > > >
>> > > > Tuesday September 1st, 11AM PST. I added a basic bullet for the
>> agenda
>> > > but
>> > > > if there is more, edit away.
>> > > >
>> > > > Patrick
>> > > >
>> > > > On Thu, Aug 27, 2020 at 11:31 AM Jasonstack Zhao Yang <
>> > > > jasonstack.z...@gmail.com> wrote:
>> > > >
>> > > > > +1
>> > > > >
>> > > > > On Thu, 27 Aug 2020 at 04:52, Ekaterina Dimitrova <
>> > > e.dimitr...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > +1
>> > > > > >
>> > > > > > On Wed, 26 Aug 2020 at 16:48, Caleb Rackliffe <
>> > > calebrackli...@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > +1
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Wed, Aug 26, 2020, 3:45 PM Patrick McFadin <
>> pmcfa...@gmail.com>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > > This is related to the discussion Jordan and I had about the
>> > > > > > contributor
>> > > > > > >
>> > > > > > > > Zoom call. Instead of open mic for any issue, call it based
>> on a
>> > > > > > > discussion
>> > > > > > >
>> > > > > > > > thread or threads for higher bandwidth discussion.
>> > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > > I would be happy to schedule on for next week to
>> specifically
>> > > discuss
>> > > > > > >
>> > > > > > > > CEP-7. I can attach the recorded call to the CEP after.
>> > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > > +1 or -1?
>> > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > > Patrick
>> > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > > On Tue, Aug 25, 2020 at 7:03 AM Joshua McKenzie <
>> > > > > jmcken...@apache.org>
>> > > > > > >
>> > > > > > > > wrote:
>> > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > > > >
>> > > > > > >
>> > > > > > > > > > Does community plan to open another discussion or CEP on
>> > > > > > >
>> > > > > > > > modularization?
>> > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > > > > We probably should have a discussion on the ML or monthly
>> > > contrib
>> > > > > > call
>> > > > > > >
>> > > > > > > > > about it first to see how aligned the interested
>> contributors
>> > > are.
>> > > > > > > Could
>> > > > > > >
>> > > > > > > > do
>> > > > > > >
>> > > > > > > > > that through CEP as well but CEP's (at least thus far
>> sans k8s
>> > > > > > > operator)
>> > > > > > >
>> > > > > > > > > tend to start with a strong, deeply thought out point of
>> view
>> > > being
>> > > > > > >
>> > > > > > > > > expressed.
>> > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > > > > On Tue, Aug 25, 2020 at 3:26 AM Jasonstack Zhao Yang <
>> > > > > > >
>> > > > > > > > > jasonstack.z...@gmail.com> wrote:
>> > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > > > > > >>> SASI's performance, specifically the search in the
>> B+
>> > > tree
>> > > > > > >
>> > > > > > > > component,
>> > > > > > >
>> > > > > > > > > > >>> depends a lot on the component file's header being
>> > > available
>> > > > > in
>> > > > > > > the
>> > > > > > >
>> > > > > > > > > > >>> pagecache. SASI benefits from (needs) nodes with
>> lots of
>> > > RAM.
>> > > > > > Is
>> > > > > > >
>> > > > > > > > SAI
>> > > > > > >
>> > > > > > > > > > bound
>> > > > > > >
>> > > > > > > > > > >>> to this same or similar limitation?
>> > > > > > >
>> > > > > > > > > >
>> > > > > > >
>> > > > > > > > > > SAI also benefits from larger memory because SAI puts
>> block
>> > > info
>> > > > > on
>> > > > > > >
>> > > > > > > > heap
>> > > > > > >
>> > > > > > > > > > for searching on-disk components and having cross-index
>> > > files on
>> > > > > > page
>> > > > > > >
>> > > > > > > > > cache
>> > > > > > >
>> > > > > > > > > > improves read performance of different indexes on the
>> same
>> > > table.
>> > > > > > >
>> > > >