User Survey results

[Patrick McFadin]

Hi everyone,

Thank you to everyone who took the time to complete the survey. There was
~150 responses which was a little shy of last year's survey but still a
good sample.

I've compiled the graphs for the questions for you to look over. There is a
link to the raw data if anyone would like to embrace your inner data
scientist and find some correlations.

https://docs.google.com/document/d/1nXKWWQui6qxeaZsJAlEeWfqUTT4Q8eFHhfNNY5kvlPg/edit?usp=sharing

Here are a few interesting insights to get you started:

1 - AI is the #1 future use case for Cassandra showing this trend affects
out community
2 - A lot of folks are still running 3.x
3 - VMs are the most common deployment today but K8s is where many are going

Reply with any questions or interesting things you find

Patrick

Re: Status of CEP-1

[Patrick McFadin]

What are we going to do with CEP-1? Cut and rescope in a new CEP or rewrite
CEP-1?

On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero 
wrote:

> Hi folks,
>
> It was great meeting some of you in person at Community over Code where
> we had a chance to discuss the Cassandra Sidecar project. A lot of
> you expressed interest in having a release of Sidecar to start using the
> existing features in the project:
>
> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
> - Cassandra Analytics support
> - Restoring SSTables from S3-compatible object storage
> - Mutual TLS authentication
> - Role base access control
> - Cluster health checks
> - Observability
> - Sidecar Client
>
> Some of the call-outs in this thread of things we need for a release:
>
> - Documentation
> - Bug fixes [1][2][3]
>
> These are other things mentioned in the thread, where we would like help
> from the community:
>
> - vNode support [4]
> - Backup support [5]
> - Bulk APIs [6]
>
> Once we have documentation and the bug fixes mentioned above, I will
> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
>
> We want the community to benefit from the features already present in
> Sidecar. The more community engagement we have, the more feature-rich
> will become.
>
> Additionally, we can leverage easy-cass-stress to have Cassandra Sidecar
> included in your Cassandra clusters, so we can easily start trying it out.
>
> Please let me know your thoughts on this.
>
> Best,
> - Francisco
>
> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
> [4] https://issues.apache.org/jira/browse/CASSANDRASC-149
> [5] https://issues.apache.org/jira/browse/CASSANDRASC-148
> [6] https://issues.apache.org/jira/browse/CASSANDRASC-3
>
> On 2024/10/03 12:05:14 Josh McKenzie wrote:
> > I'm tentatively in favor of the idea of us cutting releases for all our
> ecosystem dependencies as a blocker to cutting a major with Cassandra
> proper. I say tentatively since we've had trouble getting majors across the
> line for awhile so adding more dependencies to that feels risky, however I
> think the improvement to user experience justifies it.
> >
> > Also - I suspect the effort required to get subprojects across the line
> will be quite a bit less than the mainline DB.
> >
> > If this is something there's agreement / consensus on, I'd be happy to
> take on the role of driving that coordination in the future.
> >
> > On Wed, Oct 2, 2024, at 3:16 PM, Jon Haddad wrote:
> > > > Mostly Analytics, which should not be a blocker for Sidecar.
> > >
> > > Yes, agreed.  I'm just trying to understand the context of the vnode
> statement and how we're framing 1.0 sidecar.
> > >
> > > > We definitely need to support 5.0 for the Analytics release, but
> that's orthogonal to Sidecar.
> > >
> > > It is, unless we're endorsing the analytics library as a primary
> reason to use sidecar.  Then it becomes a dependency people rely on, and I
> don't want it blocking people from upgrading.
> > >
> > > > Yeah, definitely. I agree that we need to support the latest
> released version of Cassandra in ecosystem projects. However, without
> official releases there won't be adoption and without adoption there won't
> be feedback from the community on what features / improvements are needed.
> > >
> > > I don't expect that our first release will be feature complete, but it
> should be at least compelling.  I'm still not aware of what functionality
> exists that would meet that requirement.
> > >
> > > Think about this from the perspective of reading a blog post.  We're
> excited to announce sidecar 1.0!  Here's what you can do:
> > >
> > > 1. Backup / restore?
> > > 2. ?
> > > 3. ?
> > >
> > > All I'm asking for are 3 reasons why people should care.  If one of
> them is backups, do we provide more flexible backup targets than S3, and if
> we provide incremental / continuous backup options?  Is there a scheduler
> or do people need to roll their own?  Is it coordinated, or is the intent
> that people handle it on their own?
> > >
> > > I work with a lot of end users - this is the type of thing that
> affects people and can either help or harm the project image.
> > >
> > > Jon
> > >
> > >
> > > On Wed, Oct 2, 2024 at 2:40 PM Francisco Guerrero 
> wrote:
> > >> > By vnode support, do you mean the analytics library?  Or do other
> features
> > >> > in sidecar not work with vnodes?
> > >>
> > >> Mostly Analytics, which should not be a blocker for Sidecar. However,
> I do
> > >> feel there should be more testing around vnodes in Sidecar.
> > >>
> > >> > If we're talking about analytics, that gets a little complicated.
> Are we
> > >> > also then talking about 1.0'ing analytics?  If so, I think we need
> support
> > >> > for 5.0 and BTI there.
> > >>
> > >> We need to release Analytics at some point as well, we should have a
> similar
> > >> discuss thread regarding Ana

Re: Status of CEP-1

[Joseph Lynch]

Hi everyone!

I am curious what Dinesh's perspective is but I think the specific
enumerated scope in CEP-1 isn't super critical to be honest. That CEP
successfully (imo) built consensus that the community wants a separate
management process, and that sidecar both exists today and has useful
functionality (which is great!). I agree with Jon and others in these
threads that the functionality isn't super accessible until some of the
tickets Francisco mentioned are worked on and a release is made. I also
agree with Francisco that getting to a release, even if it is an alpha,
should be the goal - let's get to a release.

I am personally fine closing CEP-1 and saying "This CEP has been superseded
by subsequent CEPs - future work in the sidecar requiring community
consensus will have separate CEPs as needed". That doesn't mean that the
scope in CEP-1 isn't useful, and I hope some of the gaps are added in the
future, but I think we can release without them and the focus should be on
the gaps for release not the gaps in functionality with CEP-1.

Also I should mention I am extremely excited to see all the great features
that have landed and that there is a place outside the main DB for those
kinds of innovations to be tried out that doesn't conflict with the main
process. In my mind, having that place was the purpose of CEP-1, which is
done - the specific enumerated features are less important in my opinion.

-Joey

On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin  wrote:

> What are we going to do with CEP-1? Cut and rescope in a new CEP or
> rewrite CEP-1?
>
> On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero 
> wrote:
>
>> Hi folks,
>>
>> It was great meeting some of you in person at Community over Code where
>> we had a chance to discuss the Cassandra Sidecar project. A lot of
>> you expressed interest in having a release of Sidecar to start using the
>> existing features in the project:
>>
>> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
>> - Cassandra Analytics support
>> - Restoring SSTables from S3-compatible object storage
>> - Mutual TLS authentication
>> - Role base access control
>> - Cluster health checks
>> - Observability
>> - Sidecar Client
>>
>> Some of the call-outs in this thread of things we need for a release:
>>
>> - Documentation
>> - Bug fixes [1][2][3]
>>
>> These are other things mentioned in the thread, where we would like help
>> from the community:
>>
>> - vNode support [4]
>> - Backup support [5]
>> - Bulk APIs [6]
>>
>> Once we have documentation and the bug fixes mentioned above, I will
>> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
>>
>> We want the community to benefit from the features already present in
>> Sidecar. The more community engagement we have, the more feature-rich
>> will become.
>>
>> Additionally, we can leverage easy-cass-stress to have Cassandra Sidecar
>> included in your Cassandra clusters, so we can easily start trying it out.
>>
>> Please let me know your thoughts on this.
>>
>> Best,
>> - Francisco
>>
>> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
>> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
>> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
>> [4] https://issues.apache.org/jira/browse/CASSANDRASC-149
>> [5] https://issues.apache.org/jira/browse/CASSANDRASC-148
>> [6] https://issues.apache.org/jira/browse/CASSANDRASC-3
>>
>> On 2024/10/03 12:05:14 Josh McKenzie wrote:
>> > I'm tentatively in favor of the idea of us cutting releases for all our
>> ecosystem dependencies as a blocker to cutting a major with Cassandra
>> proper. I say tentatively since we've had trouble getting majors across the
>> line for awhile so adding more dependencies to that feels risky, however I
>> think the improvement to user experience justifies it.
>> >
>> > Also - I suspect the effort required to get subprojects across the line
>> will be quite a bit less than the mainline DB.
>> >
>> > If this is something there's agreement / consensus on, I'd be happy to
>> take on the role of driving that coordination in the future.
>> >
>> > On Wed, Oct 2, 2024, at 3:16 PM, Jon Haddad wrote:
>> > > > Mostly Analytics, which should not be a blocker for Sidecar.
>> > >
>> > > Yes, agreed.  I'm just trying to understand the context of the vnode
>> statement and how we're framing 1.0 sidecar.
>> > >
>> > > > We definitely need to support 5.0 for the Analytics release, but
>> that's orthogonal to Sidecar.
>> > >
>> > > It is, unless we're endorsing the analytics library as a primary
>> reason to use sidecar.  Then it becomes a dependency people rely on, and I
>> don't want it blocking people from upgrading.
>> > >
>> > > > Yeah, definitely. I agree that we need to support the latest
>> released version of Cassandra in ecosystem projects. However, without
>> official releases there won't be adoption and without adoption there won't
>> be feedback from the community on what features / improvements are needed.
>> > >
>> > > I don't exp

Re: [DISCUSS] Donating easy-cass-stress to the project

[David Capwell]

> I think we should just accept easy-cass-stress as a subproject and go
> from there.  Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.

I strongly agree with you here. The proposal is to just add the project


> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas  wrote:
> 
> Separating the two is completely fine yep -- just mentioned since 
> deprecation/removal of stress also came up in the thread.
> 
> Let's complete the donation. Just wanted to make sure we don't remove 
> compaction-stress without a substitute.
> 
> – Scott
> 
>> On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
>> 
>> 
>> I think we should just accept easy-cass-stress as a subproject and go
>> from there. Replacing stress can be handled separately and still has
>> the large issue of reconciling the build systems that I raised in the
>> beginning of this thread, but can be figured out eventually.
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote:
>>> 
>>> Scott, I think introducing replacing compaction stress as a requirement 
>>> here adds unnecessary friction to the donation process. I'd prefer to avoid 
>>> coupling the two things. Unless you or someone else is volunteering to 
>>> rewrite it I think this would effectively halt the donation, which I doubt 
>>> is your intention. Can we do that as a separate thing?
>>> 
>>> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*, 
>>> and renaming it would make it clear that it's no longer my project, that's 
>>> fine with me.
>>> 
>>> Jon
>>> 
>>> 
>>> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
 
 Supportive and would welcome the contribution as well. Jon, thanks for 
 your willingness to offer this work to the Foundation.
 
 Also supportive of considering easy-cass-stress the successor to 
 cassandra-stress.
 
 I’m fine with a directional goal of deprecating and removing 
 cassandra-stress, but would like to make sure we have a successor to 
 compaction-stress before doing so. I very rarely use cassandra-stress, but 
 compaction-stress is helpful for generating a large corpus of SSTables and 
 allowing compaction to churn through them. This is great for benching 
 changes to the read path, compaction strategies, and for evaluation of 
 hardware/VM/IO performance.
 
 https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java
 
 Apologies if this exists in easy-cass-stress today - I may have missed it. 
 Our own documentation even lacks a mention of compaction-stress. :)
 
 – Scott
 
 On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič  
 wrote:
 
 * easy-cass-stress, sorry. Everything else holds.
 
 On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič  
 wrote:
> 
> What does "replacing" actually mean? If this tool is added to a separate 
> repository, you mean like it would be put there under the "easy-cass-lab" 
> name and all source code of cassandra-stress in the Cassandra repository 
> would be removed? Are we going to deprecate what we have first or it is 
> going to be a big bang?
> 
> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think 
> that "easy-cass-lab" should be the name of a repo we are going to use. 
> For a custom tool living outside of Cassandra until now, sure, but the 
> official stress tool should not be called "easy-cass-lab". People would 
> be like ... what? IMHO we should rename it to cassandra-stress.
> 
> On Sun, Oct 13, 2024 at 8:33 PM Brad  wrote:
>> 
>> I'm +1 on replacing the existing cassandra-stress. My team did some work 
>> last Summer to remove Thrift related CLI args, but arg parsing alone is 
>> a 5K line mess. It's certainly not being well-maintained and could use a 
>> replacement.
>> 
>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie  
>> wrote:
>>> 
>>> Unsolicited .02:
>>> 
>>> - If this will eventually replace the in-tree cassandra-stress, does it 
>>> warrant a CEP ? (i'm ok with skipping, though that step might have 
>>> encouraged the questions above)
>>> 
>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>> 
>>> Given the current tool is unmaintained and doesn't (to my knowledge) 
>>> have a workflow-based usage paradigm that could be easily extended, 
>>> seems like a clear win.
>>> 
>>> 
>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>> 
>>> reply below.
>>> 
>>> 
>>> I’m terms of next steps: Mick what do we need to do next? Figure out 
>>> the answers to your questions re: getting contributor sign off?
>>> 
>>> 
>>> 
>>> The process of donation is as fo

Re: Status of CEP-1

[Francisco Guerrero]

>From my point of view CEP-1 is overly broad in terms it wants to achieve.
My understanding is that CEPs have to have a well-defined scope.

I agree with Joey that we should close CEP-1 with the features I have
proposed earlier in this thread. And have any future Sidecar work captured in
subsequent CEPs.

Best,
- Francisco

On 2024/10/14 21:58:55 Joseph Lynch wrote:
> Hi everyone!
> 
> I am curious what Dinesh's perspective is but I think the specific
> enumerated scope in CEP-1 isn't super critical to be honest. That CEP
> successfully (imo) built consensus that the community wants a separate
> management process, and that sidecar both exists today and has useful
> functionality (which is great!). I agree with Jon and others in these
> threads that the functionality isn't super accessible until some of the
> tickets Francisco mentioned are worked on and a release is made. I also
> agree with Francisco that getting to a release, even if it is an alpha,
> should be the goal - let's get to a release.
> 
> I am personally fine closing CEP-1 and saying "This CEP has been superseded
> by subsequent CEPs - future work in the sidecar requiring community
> consensus will have separate CEPs as needed". That doesn't mean that the
> scope in CEP-1 isn't useful, and I hope some of the gaps are added in the
> future, but I think we can release without them and the focus should be on
> the gaps for release not the gaps in functionality with CEP-1.
> 
> Also I should mention I am extremely excited to see all the great features
> that have landed and that there is a place outside the main DB for those
> kinds of innovations to be tried out that doesn't conflict with the main
> process. In my mind, having that place was the purpose of CEP-1, which is
> done - the specific enumerated features are less important in my opinion.
> 
> -Joey
> 
> On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin  wrote:
> 
> > What are we going to do with CEP-1? Cut and rescope in a new CEP or
> > rewrite CEP-1?
> >
> > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero 
> > wrote:
> >
> >> Hi folks,
> >>
> >> It was great meeting some of you in person at Community over Code where
> >> we had a chance to discuss the Cassandra Sidecar project. A lot of
> >> you expressed interest in having a release of Sidecar to start using the
> >> existing features in the project:
> >>
> >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
> >> - Cassandra Analytics support
> >> - Restoring SSTables from S3-compatible object storage
> >> - Mutual TLS authentication
> >> - Role base access control
> >> - Cluster health checks
> >> - Observability
> >> - Sidecar Client
> >>
> >> Some of the call-outs in this thread of things we need for a release:
> >>
> >> - Documentation
> >> - Bug fixes [1][2][3]
> >>
> >> These are other things mentioned in the thread, where we would like help
> >> from the community:
> >>
> >> - vNode support [4]
> >> - Backup support [5]
> >> - Bulk APIs [6]
> >>
> >> Once we have documentation and the bug fixes mentioned above, I will
> >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
> >>
> >> We want the community to benefit from the features already present in
> >> Sidecar. The more community engagement we have, the more feature-rich
> >> will become.
> >>
> >> Additionally, we can leverage easy-cass-stress to have Cassandra Sidecar
> >> included in your Cassandra clusters, so we can easily start trying it out.
> >>
> >> Please let me know your thoughts on this.
> >>
> >> Best,
> >> - Francisco
> >>
> >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
> >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
> >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
> >> [4] https://issues.apache.org/jira/browse/CASSANDRASC-149
> >> [5] https://issues.apache.org/jira/browse/CASSANDRASC-148
> >> [6] https://issues.apache.org/jira/browse/CASSANDRASC-3
> >>
> >> On 2024/10/03 12:05:14 Josh McKenzie wrote:
> >> > I'm tentatively in favor of the idea of us cutting releases for all our
> >> ecosystem dependencies as a blocker to cutting a major with Cassandra
> >> proper. I say tentatively since we've had trouble getting majors across the
> >> line for awhile so adding more dependencies to that feels risky, however I
> >> think the improvement to user experience justifies it.
> >> >
> >> > Also - I suspect the effort required to get subprojects across the line
> >> will be quite a bit less than the mainline DB.
> >> >
> >> > If this is something there's agreement / consensus on, I'd be happy to
> >> take on the role of driving that coordination in the future.
> >> >
> >> > On Wed, Oct 2, 2024, at 3:16 PM, Jon Haddad wrote:
> >> > > > Mostly Analytics, which should not be a blocker for Sidecar.
> >> > >
> >> > > Yes, agreed.  I'm just trying to understand the context of the vnode
> >> statement and how we're framing 1.0 sidecar.
> >> > >
> >> > > > We definitely need to support 5.0 for the Analytics rele

Re: Status of CEP-1

[Patrick McFadin]

I think that all sounds good. Let's get that new CEP started then. I think
there are opinions flying around based on last week's discussions that need
to coalesce.

Patrick

On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero 
wrote:

> From my point of view CEP-1 is overly broad in terms it wants to achieve.
> My understanding is that CEPs have to have a well-defined scope.
>
> I agree with Joey that we should close CEP-1 with the features I have
> proposed earlier in this thread. And have any future Sidecar work captured
> in
> subsequent CEPs.
>
> Best,
> - Francisco
>
> On 2024/10/14 21:58:55 Joseph Lynch wrote:
> > Hi everyone!
> >
> > I am curious what Dinesh's perspective is but I think the specific
> > enumerated scope in CEP-1 isn't super critical to be honest. That CEP
> > successfully (imo) built consensus that the community wants a separate
> > management process, and that sidecar both exists today and has useful
> > functionality (which is great!). I agree with Jon and others in these
> > threads that the functionality isn't super accessible until some of the
> > tickets Francisco mentioned are worked on and a release is made. I also
> > agree with Francisco that getting to a release, even if it is an alpha,
> > should be the goal - let's get to a release.
> >
> > I am personally fine closing CEP-1 and saying "This CEP has been
> superseded
> > by subsequent CEPs - future work in the sidecar requiring community
> > consensus will have separate CEPs as needed". That doesn't mean that the
> > scope in CEP-1 isn't useful, and I hope some of the gaps are added in the
> > future, but I think we can release without them and the focus should be
> on
> > the gaps for release not the gaps in functionality with CEP-1.
> >
> > Also I should mention I am extremely excited to see all the great
> features
> > that have landed and that there is a place outside the main DB for those
> > kinds of innovations to be tried out that doesn't conflict with the main
> > process. In my mind, having that place was the purpose of CEP-1, which is
> > done - the specific enumerated features are less important in my opinion.
> >
> > -Joey
> >
> > On Mon, Oct 14, 2024 at 4:09 PM Patrick McFadin 
> wrote:
> >
> > > What are we going to do with CEP-1? Cut and rescope in a new CEP or
> > > rewrite CEP-1?
> > >
> > > On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero <
> fran...@apache.org>
> > > wrote:
> > >
> > >> Hi folks,
> > >>
> > >> It was great meeting some of you in person at Community over Code
> where
> > >> we had a chance to discuss the Cassandra Sidecar project. A lot of
> > >> you expressed interest in having a release of Sidecar to start using
> the
> > >> existing features in the project:
> > >>
> > >> - C* adapters for versions 4.0, 4.1, 5.0 and trunk
> > >> - Cassandra Analytics support
> > >> - Restoring SSTables from S3-compatible object storage
> > >> - Mutual TLS authentication
> > >> - Role base access control
> > >> - Cluster health checks
> > >> - Observability
> > >> - Sidecar Client
> > >>
> > >> Some of the call-outs in this thread of things we need for a release:
> > >>
> > >> - Documentation
> > >> - Bug fixes [1][2][3]
> > >>
> > >> These are other things mentioned in the thread, where we would like
> help
> > >> from the community:
> > >>
> > >> - vNode support [4]
> > >> - Backup support [5]
> > >> - Bulk APIs [6]
> > >>
> > >> Once we have documentation and the bug fixes mentioned above, I will
> > >> start a thread vote for a release of Cassandra Sidecar 0.1 alpha.
> > >>
> > >> We want the community to benefit from the features already present in
> > >> Sidecar. The more community engagement we have, the more feature-rich
> > >> will become.
> > >>
> > >> Additionally, we can leverage easy-cass-stress to have Cassandra
> Sidecar
> > >> included in your Cassandra clusters, so we can easily start trying it
> out.
> > >>
> > >> Please let me know your thoughts on this.
> > >>
> > >> Best,
> > >> - Francisco
> > >>
> > >> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120
> > >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121
> > >> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122
> > >> [4] https://issues.apache.org/jira/browse/CASSANDRASC-149
> > >> [5] https://issues.apache.org/jira/browse/CASSANDRASC-148
> > >> [6] https://issues.apache.org/jira/browse/CASSANDRASC-3
> > >>
> > >> On 2024/10/03 12:05:14 Josh McKenzie wrote:
> > >> > I'm tentatively in favor of the idea of us cutting releases for all
> our
> > >> ecosystem dependencies as a blocker to cutting a major with Cassandra
> > >> proper. I say tentatively since we've had trouble getting majors
> across the
> > >> line for awhile so adding more dependencies to that feels risky,
> however I
> > >> think the improvement to user experience justifies it.
> > >> >
> > >> > Also - I suspect the effort required to get subprojects across the
> line
> > >> will be quite a bit less than the mainline DB.
> > >> >
> > >> 

Re: [DISCUSS] Donating easy-cass-stress to the project

[Jon Haddad]

Scott, I think introducing replacing compaction stress as a requirement
here adds unnecessary friction to the donation process.  I'd prefer to
avoid coupling the two things.  Unless you or someone else is volunteering
to rewrite it I think this would effectively halt the donation, which I
doubt is your intention.  Can we do that as a separate thing?

Regarding the name, I'm fine if we rename it.  My tooling is easy-cass-*,
and renaming it would make it clear that it's no longer my project, that's
fine with me.

Jon


On Sun, Oct 13, 2024 at 8:20 PM  wrote:

> Supportive and would welcome the contribution as well. Jon, thanks for
> your willingness to offer this work to the Foundation.
>
> Also supportive of considering easy-cass-stress the successor to
> cassandra-stress.
>
> I’m fine with a directional goal of deprecating and removing
> cassandra-stress, but would like to make sure we have a successor to
> compaction-stress before doing so. I very rarely use cassandra-stress, but
> compaction-stress is helpful for generating a large corpus of SSTables and
> allowing compaction to churn through them. This is great for benching
> changes to the read path, compaction strategies, and for evaluation of
> hardware/VM/IO performance.
>
>
> https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java
>
> Apologies if this exists in easy-cass-stress today - I may have missed it.
> Our own documentation even lacks a mention of compaction-stress. :)
>
> – Scott
>
> On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič 
> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič 
> wrote:
>
>> What does "replacing" actually mean? If this tool is added to a separate
>> repository, you mean  like it would be put there under the "easy-cass-lab"
>> name and all source code of cassandra-stress in the Cassandra repository
>> would be removed? Are we going to deprecate what we have first or it is
>> going to be a big bang?
>>
>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
>> that "easy-cass-lab" should be the name of a repo we are going to use.  For
>> a custom tool living outside of Cassandra until now, sure, but the official
>> stress tool should not be called "easy-cass-lab". People would be like ...
>> what? IMHO we should rename it to cassandra-stress.
>>
>> On Sun, Oct 13, 2024 at 8:33 PM Brad  wrote:
>>
>>> I'm +1 on replacing the existing cassandra-stress.  My team did some
>>> work last Summer to remove Thrift related CLI args, but arg parsing alone
>>> is a 5K line mess. It's certainly not being well-maintained and could use a
>>> replacement.
>>>
>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie 
>>> wrote:
>>>
 Unsolicited .02:

 - If this will eventually replace the in-tree cassandra-stress, does it
 warrant a CEP ?  (i'm ok with skipping, though that step might have
 encouraged the questions above)

 I'm +1 to this replacing, -0 on requiring a CEP.

 Given the current tool is unmaintained and doesn't (to my knowledge)
 have a workflow-based usage paradigm that could be easily extended, seems
 like a clear win.


 On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:

  reply below.


 I’m terms of next steps: Mick what do we need to do next? Figure out
 the answers to your questions re: getting contributor sign off?



 The process of donation is as follows… (feel free to correct me, or add
 anything)


 1. General pre-agreement from the PMC that we'll take this project in,
 and how it will fit in.

 Some questions I (personally) have are,
 - Is the PMC ok with accepting a kotlin repository into the main part
 of the project ? (I assume so, kotlin == java, just asking the question.
  this was asked before, maybe i missed any response)
 - Who are the initial three PMC members that are volunteering to be
 active ? (Jon, Jordan, and ?)
 - How will the activity in this repository maintain visibility to the
 rest of the project ? (see recent discussions wrt sidecar's activity
 silo-ing)
 - Is the repo intending to adopt general project practices ? (e.g.
 release formalities, "patch by ; reviewed by for " commit messages, etc etc
 etc.  if not, what is planned…)
 - If this will eventually replace the in-tree cassandra-stress, does it
 warrant a CEP ?  (i'm ok with skipping, though that step might have
 encouraged the questions above)


 2. IP Donation.  Start filling out the IP Donation¹ form².

 Part of this process is to get approval to donate and an ICLA from each
 individual past contributor.  In addition any company involved in past
 works must consent through either an SGA or their CCLA.  In this case, all
 work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was 

Re: [DISCUSS] Donating easy-cass-stress to the project

[Brandon Williams]

I think we should just accept easy-cass-stress as a subproject and go
from there.  Replacing stress can be handled separately and still has
the large issue of reconciling the build systems that I raised in the
beginning of this thread, but can be figured out eventually.

Kind Regards,
Brandon

On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote:
>
> Scott, I think introducing replacing compaction stress as a requirement here 
> adds unnecessary friction to the donation process.  I'd prefer to avoid 
> coupling the two things.  Unless you or someone else is volunteering to 
> rewrite it I think this would effectively halt the donation, which I doubt is 
> your intention.  Can we do that as a separate thing?
>
> Regarding the name, I'm fine if we rename it.  My tooling is easy-cass-*, and 
> renaming it would make it clear that it's no longer my project, that's fine 
> with me.
>
> Jon
>
>
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>>
>> Supportive and would welcome the contribution as well. Jon, thanks for your 
>> willingness to offer this work to the Foundation.
>>
>> Also supportive of considering easy-cass-stress the successor to 
>> cassandra-stress.
>>
>> I’m fine with a directional goal of deprecating and removing 
>> cassandra-stress, but would like to make sure we have a successor to 
>> compaction-stress before doing so. I very rarely use cassandra-stress, but 
>> compaction-stress is helpful for generating a large corpus of SSTables and 
>> allowing compaction to churn through them. This is great for benching 
>> changes to the read path, compaction strategies, and for evaluation of 
>> hardware/VM/IO performance.
>>
>> https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java
>>
>> Apologies if this exists in easy-cass-stress today - I may have missed it. 
>> Our own documentation even lacks a mention of compaction-stress. :)
>>
>> – Scott
>>
>> On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič  
>> wrote:
>>
>> * easy-cass-stress, sorry. Everything else holds.
>>
>> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič  
>> wrote:
>>>
>>> What does "replacing" actually mean? If this tool is added to a separate 
>>> repository, you mean  like it would be put there under the "easy-cass-lab" 
>>> name and all source code of cassandra-stress in the Cassandra repository 
>>> would be removed? Are we going to deprecate what we have first or it is 
>>> going to be a big bang?
>>>
>>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think 
>>> that "easy-cass-lab" should be the name of a repo we are going to use.  For 
>>> a custom tool living outside of Cassandra until now, sure, but the official 
>>> stress tool should not be called "easy-cass-lab". People would be like ... 
>>> what? IMHO we should rename it to cassandra-stress.
>>>
>>> On Sun, Oct 13, 2024 at 8:33 PM Brad  wrote:

 I'm +1 on replacing the existing cassandra-stress.  My team did some work 
 last Summer to remove Thrift related CLI args, but arg parsing alone is a 
 5K line mess. It's certainly not being well-maintained and could use a 
 replacement.

 On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie  
 wrote:
>
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does it 
> warrant a CEP ?  (i'm ok with skipping, though that step might have 
> encouraged the questions above)
>
> I'm +1 to this replacing, -0 on requiring a CEP.
>
> Given the current tool is unmaintained and doesn't (to my knowledge) have 
> a workflow-based usage paradigm that could be easily extended, seems like 
> a clear win.
>
>
> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>
>  reply below.
>
>
> I’m terms of next steps: Mick what do we need to do next? Figure out the 
> answers to your questions re: getting contributor sign off?
>
>
>
> The process of donation is as follows… (feel free to correct me, or add 
> anything)
>
>
> 1. General pre-agreement from the PMC that we'll take this project in, 
> and how it will fit in.
>
> Some questions I (personally) have are,
> - Is the PMC ok with accepting a kotlin repository into the main part of 
> the project ? (I assume so, kotlin == java, just asking the question.  
> this was asked before, maybe i missed any response)
> - Who are the initial three PMC members that are volunteering to be 
> active ? (Jon, Jordan, and ?)
> - How will the activity in this repository maintain visibility to the 
> rest of the project ? (see recent discussions wrt sidecar's activity 
> silo-ing)
> - Is the repo intending to adopt general project practices ? (e.g. 
> release formalities, "patch by ; reviewed by for " commit messages, etc 
> etc etc.  if not, what is planned…)
> - If this will eventually replace the in-tree c

Re: [DISCUSS] Donating easy-cass-stress to the project

[C. Scott Andreas]

Separating the two is completely fine yep -- just mentioned since deprecation/removal of stress also came up in the thread. Let's complete the donation. Just wanted to make sure we 
don't remove compaction-stress without a substitute. – Scott On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote: I think we should just accept 
easy-cass-stress as a subproject and go from there. Replacing stress can be handled separately and still has the large issue of reconciling the build systems that I raised in the 
beginning of this thread, but can be figured out eventually. Kind Regards, Brandon On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote: Scott, I think 
introducing replacing compaction stress as a requirement here adds unnecessary friction to the donation process. I'd prefer to avoid coupling the two things. Unless you or someone 
else is volunteering to rewrite it I think this would effectively halt the donation, which I doubt is your intention. Can we do that as a separate thing? Regarding the name, I'm 
fine if we rename it. My tooling is easy-cass-*, and renaming it would make it clear that it's no longer my project, that's fine with me. Jon On Sun, Oct 13, 2024 at 8:20 PM 
 wrote: Supportive and would welcome the contribution as well. Jon, thanks for your willingness to offer this work to the Foundation. Also supportive of 
considering easy-cass-stress the successor to cassandra-stress. I’m fine with a directional goal of deprecating and removing cassandra-stress, but would like to make sure we have a 
successor to compaction-stress before doing so. I very rarely use cassandra-stress, but compaction-stress is helpful for generating a large corpus of SSTables and allowing 
compaction to churn through them. This is great for benching changes to the read path, compaction strategies, and for evaluation of hardware/VM/IO performance. 
https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java Apologies if this exists in easy-cass-stress today - I may have 
missed it. Our own documentation even lacks a mention of compaction-stress. :) – Scott On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič  wrote: * 
easy-cass-stress, sorry. Everything else holds. On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič  wrote: What does "replacing" actually 
mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the 
Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang? Should not be easy-cass-lab renamed to 
"cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until 
now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress. On Sun, Oct 13, 
2024 at 8:33 PM Brad  wrote: I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but 
arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement. On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie 
 wrote: Unsolicited .02: - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step 
might have encouraged the questions above) I'm +1 to this replacing, -0 on requiring a CEP. Given the current tool is unmaintained and doesn't (to my knowledge) have a 
workflow-based usage paradigm that could be easily extended, seems like a clear win. On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote: reply below. I’m terms of next steps: 
Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off? The process of donation is as follows… (feel free to correct me, or add 
anything) 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in. Some questions I (personally) have are, - Is the PMC ok with accepting a 
kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response) - Who are the 
initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?) - How will the activity in this repository maintain visibility to the rest of the project ? (see 
recent discussions wrt sidecar's activity silo-ing) - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " 
commit messages, etc etc etc. if not, what is planned…) - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that 
step might have encouraged the questions above) 2. IP Donation. Start filling out the IP Donation¹ form². Part of this process is t

Re: Status of CEP-1

[Francisco Guerrero]

Hi folks,

It was great meeting some of you in person at Community over Code where
we had a chance to discuss the Cassandra Sidecar project. A lot of
you expressed interest in having a release of Sidecar to start using the
existing features in the project:

- C* adapters for versions 4.0, 4.1, 5.0 and trunk
- Cassandra Analytics support
- Restoring SSTables from S3-compatible object storage
- Mutual TLS authentication
- Role base access control
- Cluster health checks
- Observability
- Sidecar Client

Some of the call-outs in this thread of things we need for a release:

- Documentation
- Bug fixes [1][2][3]

These are other things mentioned in the thread, where we would like help
from the community:

- vNode support [4]
- Backup support [5]
- Bulk APIs [6]

Once we have documentation and the bug fixes mentioned above, I will
start a thread vote for a release of Cassandra Sidecar 0.1 alpha.

We want the community to benefit from the features already present in
Sidecar. The more community engagement we have, the more feature-rich
will become.

Additionally, we can leverage easy-cass-stress to have Cassandra Sidecar
included in your Cassandra clusters, so we can easily start trying it out.

Please let me know your thoughts on this.

Best,
- Francisco

[1] https://issues.apache.org/jira/browse/CASSANDRASC-120
[2] https://issues.apache.org/jira/browse/CASSANDRASC-121
[3] https://issues.apache.org/jira/browse/CASSANDRASC-122
[4] https://issues.apache.org/jira/browse/CASSANDRASC-149
[5] https://issues.apache.org/jira/browse/CASSANDRASC-148
[6] https://issues.apache.org/jira/browse/CASSANDRASC-3

On 2024/10/03 12:05:14 Josh McKenzie wrote:
> I'm tentatively in favor of the idea of us cutting releases for all our 
> ecosystem dependencies as a blocker to cutting a major with Cassandra proper. 
> I say tentatively since we've had trouble getting majors across the line for 
> awhile so adding more dependencies to that feels risky, however I think the 
> improvement to user experience justifies it.
> 
> Also - I suspect the effort required to get subprojects across the line will 
> be quite a bit less than the mainline DB.
> 
> If this is something there's agreement / consensus on, I'd be happy to take 
> on the role of driving that coordination in the future.
> 
> On Wed, Oct 2, 2024, at 3:16 PM, Jon Haddad wrote:
> > > Mostly Analytics, which should not be a blocker for Sidecar.
> > 
> > Yes, agreed.  I'm just trying to understand the context of the vnode 
> > statement and how we're framing 1.0 sidecar.
> > 
> > > We definitely need to support 5.0 for the Analytics release, but that's 
> > > orthogonal to Sidecar.
> > 
> > It is, unless we're endorsing the analytics library as a primary reason to 
> > use sidecar.  Then it becomes a dependency people rely on, and I don't want 
> > it blocking people from upgrading. 
> > 
> > > Yeah, definitely. I agree that we need to support the latest released 
> > > version of Cassandra in ecosystem projects. However, without official 
> > > releases there won't be adoption and without adoption there won't be 
> > > feedback from the community on what features / improvements are needed.
> > 
> > I don't expect that our first release will be feature complete, but it 
> > should be at least compelling.  I'm still not aware of what functionality 
> > exists that would meet that requirement. 
> > 
> > Think about this from the perspective of reading a blog post.  We're 
> > excited to announce sidecar 1.0!  Here's what you can do:
> > 
> > 1. Backup / restore?
> > 2. ?
> > 3. ?
> > 
> > All I'm asking for are 3 reasons why people should care.  If one of them is 
> > backups, do we provide more flexible backup targets than S3, and if we 
> > provide incremental / continuous backup options?  Is there a scheduler or 
> > do people need to roll their own?  Is it coordinated, or is the intent that 
> > people handle it on their own? 
> > 
> > I work with a lot of end users - this is the type of thing that affects 
> > people and can either help or harm the project image.
> > 
> > Jon
> > 
> > 
> > On Wed, Oct 2, 2024 at 2:40 PM Francisco Guerrero  
> > wrote:
> >> > By vnode support, do you mean the analytics library?  Or do other 
> >> > features
> >> > in sidecar not work with vnodes?
> >> 
> >> Mostly Analytics, which should not be a blocker for Sidecar. However, I do
> >> feel there should be more testing around vnodes in Sidecar.
> >> 
> >> > If we're talking about analytics, that gets a little complicated.  Are we
> >> > also then talking about 1.0'ing analytics?  If so, I think we need 
> >> > support
> >> > for 5.0 and BTI there.
> >> 
> >> We need to release Analytics at some point as well, we should have a 
> >> similar
> >> discuss thread regarding Analytics. We definitely need to support 5.0 for 
> >> the
> >> Analytics release, but that's orthogonal to Sidecar.
> >> 
> >> > Increasing the size of the ecosystem is challenging...
> >> 
> >> Yeah, definitely. I agree that we n

Re: GoCQL module name change and next release

[Rolo, Carlos via dev]

I agree that should be 1) and 2) together.

Regarding the PR review for 2.0, I can look into some (I'm not proficient with 
Go, it has been a long time) but for triaging what should be in a major I can 
surely help. Low hanging fruit should also not be a problem for me to review.

Are we looking to review/triaging all existing PRs?

Thanks,

Carlos

From: João Reis 
Sent: 11 October 2024 16:03
To: dev@cassandra.apache.org 
Subject: Re: GoCQL module name change and next release

You don't often get email from joaor...@apache.org. Learn why this is 
important
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments



I like that too, I initially considered proposing that but thought I'd propose 
delivering v5 and vector support faster but +1 on making these two features a 
part of 2.0.0 instead.

Štefan Miklošovič mailto:smikloso...@apache.org>> 
escreveu (quinta, 10/10/2024 à(s) 23:37):

I would do 1) and 2) together. I would rename the module in 2.0.0 and there 
would be v5 and vector support as well. It would motivate us to get v5 and 
vector out while using that opportunity to rename it to 2.0.0.

On Thu, Oct 10, 2024 at 11:42 AM João Reis 
mailto:joaor...@apache.org>> wrote:
Hi,

Following the GoCQL donation we need to change the module name so it matches 
the new repo URL. Currently users have to keep using the old name unless they 
add a rewrite to go.mod.

There was a discussion on what the approach should be on #1776 [1] and I've 
created CASSANDRA-19993 [2] to track this work. Since this is a breaking change 
(it requires users to modify their imports or add a rewrite to go.mod) we need 
to bump the major version when we do this.

With this in mind, there's some topics to discuss:

1) When do we want to make this module name change happen? We can keep doing 
minor releases under the old module name but it is a bit confusing for new 
users to have to import gocql using a Github repo URL that effectively no 
longer exists. Also the amount of users that will be impacted by the module 
name change will only increase the longer we wait.

2) Should we take this opportunity to include other breaking change related 
issues with the module name change? Martin mentioned on the gocql mailing list 
[3] that there's a few issues on Github that are tagged with "semver-major" [4] 
and these should be considered for a new major release.

My take on these topics is that we should work on some of those tagged issues 
when we decide to change the module name as long as these breaking changes 
don't require users to significantly rewrite parts of their application. We 
should make this upgrade and module name change to be the least intrusive as 
possible for users. Note that the cassandra-gocql-driver project officially 
maintains the latest release only (single active branch) so doing a major 
release effectively drops support for the previous major immediately which 
means we have an even stronger incentive to make the upgrade as easy as 
possible.

I'm planning on reviewing protocol v5 and vector support PRs soon and we should 
probably make these 2 contributions available to users as soon as possible. To 
do this we can do a minor release before we start working on the next major. 
I'm also open to the idea that we could postpone the major release development 
and keep doing minor releases for a little longer under the old module name.

In summary, my proposal for a short to medium term roadmap is:

1) Release 1.8.0 with v5 and vector support (and potentially other small PRs, 
I've only looked at these 2 issues yet)
2) Release 2.0.0 with the module name change, some (if not all) of the 
"semver-major" tagged issues and other contributions

Let me know your thoughts,
João Reis

[1] https://github.com/apache/cassandra-gocql-driver/issues/1776
[2] https://issues.apache.org/jira/browse/CASSANDRA-19993
[3] https://groups.google.com/g/gocql/c/v0FruczBb2w/m/7Hc3_W9QCgAJ
[4] 
https://github.com/apache/cassandra-gocql-driver/issues?q=is%3Aopen+is%3Aissue+label%3Asemver-major