Re: [DISCUSS] Should we deprecate / freeze python dtests

[Benjamin Lerer]

>
> They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.


This is actually my main concern. What is the real gap between the in-JVM
tests server instance and a server as run by python DTests?

Le mar. 29 mars 2022 à 00:08, bened...@apache.org  a
écrit :

> > Other than that, it can be problematic to test upgrades when the
> starting version must run with a different Java version than the end release
>
>
>
> python upgrade tests seem to be particularly limited (from a quick skim,
> primarily testing major upgrade points that are now long in the past), so
> I’m not sure how much of a penalty this is today in practice - but it might
> well become a problem.
>
>
>
> There’s several questions to answer, namely how many versions we want to:
>
>
>
> - test upgrades across
>
> - maintain backwards compatibility of the in-jvm dtest api across
>
> - support a given JVM for
>
>
>
> However, if we need to, we can probably use RMI to transparently support
> multiple JVMs for tests that require it. Since we already use serialization
> to cross the ClassLoader boundary it might not even be very difficult.
>
>
>
>
>
> *From: *Jacek Lewandowski 
> *Date: *Monday, 28 March 2022 at 22:30
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> Although I like in-jvm DTests for many scenarios, I can see that they do
> not test the production code as it is. They use a separate
> implementation of instance initialization and thus they test the test
> server rather than the real node. Other than that, it can be problematic to
> test upgrades when the starting version must run with a different Java
> version than the end release. One more thing I've been observing sometimes
> is high consumption of metaspace, which does not seem to be cleaned after
> individual test cases. Given each started instance uses a dedicated class
> loader there is some amount of trash left and when there are a couple of
> multi-node test cases in a single test class, it sometimes happens that the
> test fail with out of memory in metaspace error.
>
>
>
> Thanks,
>
> Jacek
>
>
>
> On Mon, Mar 28, 2022 at 10:06 PM David Capwell  wrote:
>
> I am back and the work for trunk to support vnode is at the last stage of
> review; I had not planned to backport the changes to other branches (aka,
> older branches would only support single token), so if someone would like
> to pick up this work it is rather LHF after 17332 goes in (see trunk patch GH
> PR: trunk ).
>
>
>
> I am in favor of deprecating python dtests, and agree we should figure out
> what the gaps are (once vnode support is merged) so we can either shrink
> them or special case to unfreeze (such as startup changes being allowed).
>
>
>
> On Mar 14, 2022, at 6:13 AM, Josh McKenzie  wrote:
>
>
>
> vnode support for in-jvm dtests is in flight and fairly straightforward:
>
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-17332
>
>
>
> David's OOO right now but I suspect we can get this in in April some time.
>
>
>
> On Mon, Mar 14, 2022, at 8:36 AM, bened...@apache.org wrote:
>
> This is the limitation I mentioned. I think this is solely a question of
> supplying an initial config that uses vnodes, i.e. that specifies multiple
> tokens for each node. It is not really a limitation – I believe a dtest
> could be written today using vnodes, by overriding the config’s tokens. It
> does look like the token handling has been refactored since the initial
> implementation to make this a little uglier than should be necessary.
>
>
>
> We should make this trivial, anyway, and perhaps offer a way to run all of
> the dtests with vnodes (and suitably annotating those that cannot be run
> with vnodes). This should be quite easy.
>
>
>
>
>
> *From: *Andrés de la Peña 
> *Date: *Monday, 14 March 2022 at 12:28
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> Last time I checked there wasn't support for vnodes on in-jvm dtests,
> which seems an important limitation.
>
>
>
> On Mon, 14 Mar 2022 at 12:24, bened...@apache.org 
> wrote:
>
> I am strongly in favour of deprecating python dtests in all cases where
> they are currently superseded by in-jvm dtests. They are environmentally
> more challenging to work with, causing many problems on local and remote
> machines. They are harder to debug, slower, flakier, and mostly less
> sophisticated.
>
>
>
> > all focus on getting the in-jvm framework robust enough to cover
> edge-cases
>
>
>
> Would be great to collect gaps. I think it’s just vnodes, which is by no
> means a fundamental limitation? There may also be some stuff to do
> startup/shutdown and environmental scripts, that may be a niche we retain
> something like python dtests for.
>
>
>
> > people aren’t familiar
>
>
>
> I would be interested to hear from these folk to understand their co

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Paulo Motta]

> They use a separate implementation of instance initialization and thus
they test the test server rather than the real node.

I also have this concern. When adding a new service on CASSANDRA-16789 we
had to explicitly modify the in-jvm dtest server to match the behavior from
the actual server [1] (this is just a minor example but I remember having
to do something similar on other tickets).

Besides having a steep learning curve since users need to be familiar with
the in-jvm dtest framework in order to add new functionality not supported
by it, this is potentially unsafe, since the implementations can diverge
without being caught by tests.

Is there any way we could avoid duplicating functionality on the test
server and use the same initialization code on in-jvm dtests?

[1] -
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd#diff-321b52220c5bd0aaadf275a845143eb208c889c2696ba0d48a5fc880551131d8R735

Em ter., 29 de mar. de 2022 às 04:22, Benjamin Lerer 
escreveu:

> They use a separate implementation of instance initialization and thus
>> they test the test server rather than the real node.
>
>
> This is actually my main concern. What is the real gap between the in-JVM
> tests server instance and a server as run by python DTests?
>
> Le mar. 29 mars 2022 à 00:08, bened...@apache.org  a
> écrit :
>
>> > Other than that, it can be problematic to test upgrades when the
>> starting version must run with a different Java version than the end release
>>
>>
>>
>> python upgrade tests seem to be particularly limited (from a quick skim,
>> primarily testing major upgrade points that are now long in the past), so
>> I’m not sure how much of a penalty this is today in practice - but it might
>> well become a problem.
>>
>>
>>
>> There’s several questions to answer, namely how many versions we want to:
>>
>>
>>
>> - test upgrades across
>>
>> - maintain backwards compatibility of the in-jvm dtest api across
>>
>> - support a given JVM for
>>
>>
>>
>> However, if we need to, we can probably use RMI to transparently support
>> multiple JVMs for tests that require it. Since we already use serialization
>> to cross the ClassLoader boundary it might not even be very difficult.
>>
>>
>>
>>
>>
>> *From: *Jacek Lewandowski 
>> *Date: *Monday, 28 March 2022 at 22:30
>> *To: *dev@cassandra.apache.org 
>> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>>
>> Although I like in-jvm DTests for many scenarios, I can see that they do
>> not test the production code as it is. They use a separate
>> implementation of instance initialization and thus they test the test
>> server rather than the real node. Other than that, it can be problematic to
>> test upgrades when the starting version must run with a different Java
>> version than the end release. One more thing I've been observing sometimes
>> is high consumption of metaspace, which does not seem to be cleaned after
>> individual test cases. Given each started instance uses a dedicated class
>> loader there is some amount of trash left and when there are a couple of
>> multi-node test cases in a single test class, it sometimes happens that the
>> test fail with out of memory in metaspace error.
>>
>>
>>
>> Thanks,
>>
>> Jacek
>>
>>
>>
>> On Mon, Mar 28, 2022 at 10:06 PM David Capwell 
>> wrote:
>>
>> I am back and the work for trunk to support vnode is at the last stage of
>> review; I had not planned to backport the changes to other branches (aka,
>> older branches would only support single token), so if someone would like
>> to pick up this work it is rather LHF after 17332 goes in (see trunk patch GH
>> PR: trunk ).
>>
>>
>>
>> I am in favor of deprecating python dtests, and agree we should figure
>> out what the gaps are (once vnode support is merged) so we can either
>> shrink them or special case to unfreeze (such as startup changes being
>> allowed).
>>
>>
>>
>> On Mar 14, 2022, at 6:13 AM, Josh McKenzie  wrote:
>>
>>
>>
>> vnode support for in-jvm dtests is in flight and fairly straightforward:
>>
>>
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-17332
>>
>>
>>
>> David's OOO right now but I suspect we can get this in in April some time.
>>
>>
>>
>> On Mon, Mar 14, 2022, at 8:36 AM, bened...@apache.org wrote:
>>
>> This is the limitation I mentioned. I think this is solely a question of
>> supplying an initial config that uses vnodes, i.e. that specifies multiple
>> tokens for each node. It is not really a limitation – I believe a dtest
>> could be written today using vnodes, by overriding the config’s tokens. It
>> does look like the token handling has been refactored since the initial
>> implementation to make this a little uglier than should be necessary.
>>
>>
>>
>> We should make this trivial, anyway, and perhaps offer a way to run all
>> of the dtests with vnodes (and suitably annotating those that cannot be run
>> with vnodes). This should be quite easy.
>>
>>

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Paulo Motta]

To elaborate a bit on the steep learning curve point, when mentoring new
contributors on a couple of occasions I told them to "just write a python
dtest" because we had no idea on how to test that functionality on in-jvm
tests while the python dtest was fairly straightforward to implement (I
can't recall exactly what feature was it but I can dig if necessary).

While we might be already familiar with the in-jvm dtest framework due to
our exposure to it, we shouldn't neglect that there is a significant
learning curve associated with it for new contributors which IMO is much
lower for pyhton dtests. So we should at least write extensive
documentation on how to use/modify in-jvm dtest framework before
deprecating python dtests.

Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta 
escreveu:

> > They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.
>
> I also have this concern. When adding a new service on CASSANDRA-16789 we
> had to explicitly modify the in-jvm dtest server to match the behavior from
> the actual server [1] (this is just a minor example but I remember having
> to do something similar on other tickets).
>
> Besides having a steep learning curve since users need to be familiar with
> the in-jvm dtest framework in order to add new functionality not supported
> by it, this is potentially unsafe, since the implementations can diverge
> without being caught by tests.
>
> Is there any way we could avoid duplicating functionality on the test
> server and use the same initialization code on in-jvm dtests?
>
> [1] -
> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd#diff-321b52220c5bd0aaadf275a845143eb208c889c2696ba0d48a5fc880551131d8R735
>
> Em ter., 29 de mar. de 2022 às 04:22, Benjamin Lerer 
> escreveu:
>
>> They use a separate implementation of instance initialization and thus
>>> they test the test server rather than the real node.
>>
>>
>> This is actually my main concern. What is the real gap between the in-JVM
>> tests server instance and a server as run by python DTests?
>>
>> Le mar. 29 mars 2022 à 00:08, bened...@apache.org 
>> a écrit :
>>
>>> > Other than that, it can be problematic to test upgrades when the
>>> starting version must run with a different Java version than the end release
>>>
>>>
>>>
>>> python upgrade tests seem to be particularly limited (from a quick skim,
>>> primarily testing major upgrade points that are now long in the past), so
>>> I’m not sure how much of a penalty this is today in practice - but it might
>>> well become a problem.
>>>
>>>
>>>
>>> There’s several questions to answer, namely how many versions we want to:
>>>
>>>
>>>
>>> - test upgrades across
>>>
>>> - maintain backwards compatibility of the in-jvm dtest api across
>>>
>>> - support a given JVM for
>>>
>>>
>>>
>>> However, if we need to, we can probably use RMI to transparently support
>>> multiple JVMs for tests that require it. Since we already use serialization
>>> to cross the ClassLoader boundary it might not even be very difficult.
>>>
>>>
>>>
>>>
>>>
>>> *From: *Jacek Lewandowski 
>>> *Date: *Monday, 28 March 2022 at 22:30
>>> *To: *dev@cassandra.apache.org 
>>> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>>>
>>> Although I like in-jvm DTests for many scenarios, I can see that they do
>>> not test the production code as it is. They use a separate
>>> implementation of instance initialization and thus they test the test
>>> server rather than the real node. Other than that, it can be problematic to
>>> test upgrades when the starting version must run with a different Java
>>> version than the end release. One more thing I've been observing sometimes
>>> is high consumption of metaspace, which does not seem to be cleaned after
>>> individual test cases. Given each started instance uses a dedicated class
>>> loader there is some amount of trash left and when there are a couple of
>>> multi-node test cases in a single test class, it sometimes happens that the
>>> test fail with out of memory in metaspace error.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Jacek
>>>
>>>
>>>
>>> On Mon, Mar 28, 2022 at 10:06 PM David Capwell 
>>> wrote:
>>>
>>> I am back and the work for trunk to support vnode is at the last stage
>>> of review; I had not planned to backport the changes to other branches
>>> (aka, older branches would only support single token), so if someone would
>>> like to pick up this work it is rather LHF after 17332 goes in (see trunk
>>> patch GH PR: trunk ).
>>>
>>>
>>>
>>> I am in favor of deprecating python dtests, and agree we should figure
>>> out what the gaps are (once vnode support is merged) so we can either
>>> shrink them or special case to unfreeze (such as startup changes being
>>> allowed).
>>>
>>>
>>>
>>> On Mar 14, 2022, at 6:13 AM, Josh McKenzie  wrote:
>>>
>>>
>>>
>>> vnode support for in-jvm dtests is in fligh

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Josh McKenzie]

> we should at least write extensive documentation on how to use/modify in-jvm 
> dtest framework before deprecating python dtests.
We should have this for all our testing frameworks period, in-jvm dtest, python 
dtest, and ccm. They're woefully under-documented IMO.

On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
> To elaborate a bit on the steep learning curve point, when mentoring new 
> contributors on a couple of occasions I told them to "just write a python 
> dtest" because we had no idea on how to test that functionality on in-jvm 
> tests while the python dtest was fairly straightforward to implement (I can't 
> recall exactly what feature was it but I can dig if necessary).
> 
> While we might be already familiar with the in-jvm dtest framework due to our 
> exposure to it, we shouldn't neglect that there is a significant learning 
> curve associated with it for new contributors which IMO is much lower for 
> pyhton dtests. So we should at least write extensive documentation on how to 
> use/modify in-jvm dtest framework before deprecating python dtests.
> 
> Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta  
> escreveu:
>> > They use a separate implementation of instance initialization and thus 
>> > they test the test server rather than the real node. 
>> 
>> I also have this concern. When adding a new service on CASSANDRA-16789 we 
>> had to explicitly modify the in-jvm dtest server to match the behavior from 
>> the actual server [1] (this is just a minor example but I remember having to 
>> do something similar on other tickets). 
>> 
>> Besides having a steep learning curve since users need to be familiar with 
>> the in-jvm dtest framework in order to add new functionality not supported 
>> by it, this is potentially unsafe, since the implementations can diverge 
>> without being caught by tests.
>> 
>> Is there any way we could avoid duplicating functionality on the test server 
>> and use the same initialization code on in-jvm dtests?
>> 
>> [1] - 
>> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd#diff-321b52220c5bd0aaadf275a845143eb208c889c2696ba0d48a5fc880551131d8R735
>> 
>> Em ter., 29 de mar. de 2022 às 04:22, Benjamin Lerer  
>> escreveu:
 They use a separate implementation of instance initialization and thus 
 they test the test server rather than the real node.
>>> 
>>> This is actually my main concern. What is the real gap between the in-JVM 
>>> tests server instance and a server as run by python DTests?  
>>> 
>>> Le mar. 29 mars 2022 à 00:08, bened...@apache.org  a 
>>> écrit :
 > Other than that, it can be problematic to test upgrades when the 
 > starting version must run with a different Java version than the end 
 > release
 __ __
 python upgrade tests seem to be particularly limited (from a quick skim, 
 primarily testing major upgrade points that are now long in the past), so 
 I’m not sure how much of a penalty this is today in practice - but it 
 might well become a problem.
 __ __
 There’s several questions to answer, namely how many versions we want 
 to:
 __ __
 - test upgrades across
 - maintain backwards compatibility of the in-jvm dtest api across
 - support a given JVM for
 __ __
 However, if we need to, we can probably use RMI to transparently support 
 multiple JVMs for tests that require it. Since we already use 
 serialization to cross the ClassLoader boundary it might not even be very 
 difficult.
 __ __
 __ __
 *From: *Jacek Lewandowski 
 *Date: *Monday, 28 March 2022 at 22:30
 *To: *dev@cassandra.apache.org 
 *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
 Although I like in-jvm DTests for many scenarios, I can see that they do 
 not test the production code as it is. They use a separate implementation 
 of instance initialization and thus they test the test server rather than 
 the real node. Other than that, it can be problematic to test upgrades 
 when the starting version must run with a different Java version than the 
 end release. One more thing I've been observing sometimes is high 
 consumption of metaspace, which does not seem to be cleaned after 
 individual test cases. Given each started instance uses a dedicated class 
 loader there is some amount of trash left and when there are a couple of 
 multi-node test cases in a single test class, it sometimes happens that 
 the test fail with out of memory in metaspace error.
 __ __
 Thanks,
 Jacek
 __ __
 On Mon, Mar 28, 2022 at 10:06 PM David Capwell  
 wrote:
> I am back and the work for trunk to support vnode is at the last stage of 
> review; I had not planned to backport the changes to other branches (aka, 
> older branches would only support single token), so if someone would like 
> to pic

Re: [DISCUSS] Should we deprecate / freeze python dtests

[David Capwell]

> They use a separate implementation of instance initialization and thus they 
> test the test server rather than the real node.

I think we can get rid of this by extending CassandraDaemon, just need to add a 
few hooks to mock out gossip/internode/client (for cases where the mocks are 
desired), and when mocks are not desired just run the real logic.

Too many times I have had to make the 2 more in-line, and this is hard to 
maintain… we should fix this and feel this is 100% fixable

> we shouldn't neglect that there is a significant learning curve associated 
> with it for new contributors which IMO is much lower for pyhton dtests


I am curious about this comment.  When I first joined I learned jvm-dtest 
within an hour and started walking Repair code in a debugger (and this was way 
before the improvements that let us do things like nodetool)… python dtest took 
weeks to get working correctly (still having issues with the MBean library we 
use… so have to comment out error handling to get some tests to pass)….

Maybe we could have some example docs showing how to do the same in both tools? 
 Honestly Cluster.build(3).withConfig(c -> c.with(Feature.values())).start() 
matches 95% of python dtest tests (the withConfig logic is a bit cryptic), so 
don’t think the docs would be too much work

> On Mar 29, 2022, at 5:48 AM, Josh McKenzie  wrote:
> 
>> we should at least write extensive documentation on how to use/modify in-jvm 
>> dtest framework before deprecating python dtests.
> We should have this for all our testing frameworks period, in-jvm dtest, 
> python dtest, and ccm. They're woefully under-documented IMO.
> 
> On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
>> To elaborate a bit on the steep learning curve point, when mentoring new 
>> contributors on a couple of occasions I told them to "just write a python 
>> dtest" because we had no idea on how to test that functionality on in-jvm 
>> tests while the python dtest was fairly straightforward to implement (I 
>> can't recall exactly what feature was it but I can dig if necessary).
>> 
>> While we might be already familiar with the in-jvm dtest framework due to 
>> our exposure to it, we shouldn't neglect that there is a significant 
>> learning curve associated with it for new contributors which IMO is much 
>> lower for pyhton dtests. So we should at least write extensive documentation 
>> on how to use/modify in-jvm dtest framework before deprecating python dtests.
>> 
>> Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta > > escreveu:
>> > They use a separate implementation of instance initialization and thus 
>> > they test the test server rather than the real node. 
>> 
>> I also have this concern. When adding a new service on CASSANDRA-16789 we 
>> had to explicitly modify the in-jvm dtest server to match the behavior from 
>> the actual server [1] (this is just a minor example but I remember having to 
>> do something similar on other tickets). 
>> 
>> Besides having a steep learning curve since users need to be familiar with 
>> the in-jvm dtest framework in order to add new functionality not supported 
>> by it, this is potentially unsafe, since the implementations can diverge 
>> without being caught by tests.
>> 
>> Is there any way we could avoid duplicating functionality on the test server 
>> and use the same initialization code on in-jvm dtests?
>> 
>> [1] - 
>> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd#diff-321b52220c5bd0aaadf275a845143eb208c889c2696ba0d48a5fc880551131d8R735
>>  
>> 
>> 
>> Em ter., 29 de mar. de 2022 às 04:22, Benjamin Lerer > > escreveu:
>> They use a separate implementation of instance initialization and thus they 
>> test the test server rather than the real node.
>> 
>> This is actually my main concern. What is the real gap between the in-JVM 
>> tests server instance and a server as run by python DTests?  
>> 
>> Le mar. 29 mars 2022 à 00:08, bened...@apache.org 
>>  > > a écrit :
>> > Other than that, it can be problematic to test upgrades when the starting 
>> > version must run with a different Java version than the end release
>> 
>>  
>> 
>> python upgrade tests seem to be particularly limited (from a quick skim, 
>> primarily testing major upgrade points that are now long in the past), so 
>> I’m not sure how much of a penalty this is today in practice - but it might 
>> well become a problem.
>> 
>>  
>> 
>> There’s several questions to answer, namely how many versions we want to:
>> 
>>  
>> 
>> - test upgrades across
>> 
>> - maintain backwards compatibility of the in-jvm dtest api across
>> 
>> - support a given JVM for
>> 
>>  
>> 
>> However, if we need to, we can probably use RM

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Ekaterina Dimitrova]

One thing that we can add to docs is for people how to update the in-jvm
framework and test their patches before asking for in-jvm api release. The
assumption is those won’t be many updates needed I think, but it is good to
be documented.

On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:

> They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.
>
>
> I think we can get rid of this by extending CassandraDaemon, just need to
> add a few hooks to mock out gossip/internode/client (for cases where the
> mocks are desired), and when mocks are not desired just run the real logic.
>
> Too many times I have had to make the 2 more in-line, and this is hard to
> maintain… we should fix this and feel this is 100% fixable
>
> we shouldn't neglect that there is a significant learning curve associated
> with it for new contributors which IMO is much lower for pyhton dtests
>
>
> I am curious about this comment.  When I first joined I learned jvm-dtest
> within an hour and started walking Repair code in a debugger (and this was
> way before the improvements that let us do things like nodetool)… python
> dtest took weeks to get working correctly (still having issues with the
> MBean library we use… so have to comment out error handling to get some
> tests to pass)….
>
> Maybe we could have some example docs showing how to do the same in both
> tools?  Honestly Cluster.build(3).withConfig(c ->
> c.with(Feature.values())).start() matches 95% of python dtest tests (the
> withConfig logic is a bit cryptic), so don’t think the docs would be too
> much work
>
>
> On Mar 29, 2022, at 5:48 AM, Josh McKenzie  wrote:
>
> we should at least write extensive documentation on how to use/modify
> in-jvm dtest framework before deprecating python dtests.
>
> We should have this for all our testing frameworks period, in-jvm dtest,
> python dtest, and ccm. They're woefully under-documented IMO.
>
> On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
>
> To elaborate a bit on the steep learning curve point, when mentoring new
> contributors on a couple of occasions I told them to "just write a python
> dtest" because we had no idea on how to test that functionality on in-jvm
> tests while the python dtest was fairly straightforward to implement (I
> can't recall exactly what feature was it but I can dig if necessary).
>
> While we might be already familiar with the in-jvm dtest framework due to
> our exposure to it, we shouldn't neglect that there is a significant
> learning curve associated with it for new contributors which IMO is much
> lower for pyhton dtests. So we should at least write extensive
> documentation on how to use/modify in-jvm dtest framework before
> deprecating python dtests.
>
> Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta <
> pauloricard...@gmail.com> escreveu:
>
> > They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.
>
> I also have this concern. When adding a new service on CASSANDRA-16789 we
> had to explicitly modify the in-jvm dtest server to match the behavior from
> the actual server [1] (this is just a minor example but I remember having
> to do something similar on other tickets).
>
> Besides having a steep learning curve since users need to be familiar with
> the in-jvm dtest framework in order to add new functionality not supported
> by it, this is potentially unsafe, since the implementations can diverge
> without being caught by tests.
>
> Is there any way we could avoid duplicating functionality on the test
> server and use the same initialization code on in-jvm dtests?
>
> [1] -
> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd#diff-321b52220c5bd0aaadf275a845143eb208c889c2696ba0d48a5fc880551131d8R735
>
> Em ter., 29 de mar. de 2022 às 04:22, Benjamin Lerer 
> escreveu:
>
> They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.
>
>
> This is actually my main concern. What is the real gap between the in-JVM
> tests server instance and a server as run by python DTests?
>
> Le mar. 29 mars 2022 à 00:08, bened...@apache.org  a
> écrit :
>
> > Other than that, it can be problematic to test upgrades when the
> starting version must run with a different Java version than the end release
>
>
>
> python upgrade tests seem to be particularly limited (from a quick skim,
> primarily testing major upgrade points that are now long in the past), so
> I’m not sure how much of a penalty this is today in practice - but it might
> well become a problem.
>
>
>
> There’s several questions to answer, namely how many versions we want to:
>
>
>
> - test upgrades across
>
> - maintain backwards compatibility of the in-jvm dtest api across
>
> - support a given JVM for
>
>
>
> However, if we need to, we can probably use RMI to transparently support
> multiple JVMs for tests th

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Paulo Motta]

> I am curious about this comment.  When I first joined I learned jvm-dtest
within an hour and started walking Repair code in a debugger (and this was
way before the improvements that let us do things like nodetool)… python
dtest took weeks to get working correctly (still having issues with the
MBean library we use… so have to comment out error handling to get some
tests to pass)….

Thanks for sharing your perspective. In fact there is a high learning curve
to setup cassandra-dtest environment, but once it's working it's pretty
straightforward to test any existing or new functionality.

I think with in-jvm dtests you don't have the hassle of setting up a
different environment and this is a great motivator to standardize on this
solution. The main difficulty I had was testing features not supported by
the framework, which require you to extend the framework. I don't recall
having to extend ccm/cassandra-dtest many times when working on new
features.

Perhaps this has improved recently and we no longer need to worry about
extending the framework or duplicating code when testing new functionality.

Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova <
e.dimitr...@gmail.com> escreveu:

> One thing that we can add to docs is for people how to update the in-jvm
> framework and test their patches before asking for in-jvm api release. The
> assumption is those won’t be many updates needed I think, but it is good to
> be documented.
>
> On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:
>
>> They use a separate implementation of instance initialization and thus
>> they test the test server rather than the real node.
>>
>>
>> I think we can get rid of this by extending CassandraDaemon, just need to
>> add a few hooks to mock out gossip/internode/client (for cases where the
>> mocks are desired), and when mocks are not desired just run the real logic.
>>
>> Too many times I have had to make the 2 more in-line, and this is hard to
>> maintain… we should fix this and feel this is 100% fixable
>>
>> we shouldn't neglect that there is a significant learning curve
>> associated with it for new contributors which IMO is much lower for pyhton
>> dtests
>>
>>
>> I am curious about this comment.  When I first joined I learned jvm-dtest
>> within an hour and started walking Repair code in a debugger (and this was
>> way before the improvements that let us do things like nodetool)… python
>> dtest took weeks to get working correctly (still having issues with the
>> MBean library we use… so have to comment out error handling to get some
>> tests to pass)….
>>
>> Maybe we could have some example docs showing how to do the same in both
>> tools?  Honestly Cluster.build(3).withConfig(c ->
>> c.with(Feature.values())).start() matches 95% of python dtest tests (the
>> withConfig logic is a bit cryptic), so don’t think the docs would be too
>> much work
>>
>>
>> On Mar 29, 2022, at 5:48 AM, Josh McKenzie  wrote:
>>
>> we should at least write extensive documentation on how to use/modify
>> in-jvm dtest framework before deprecating python dtests.
>>
>> We should have this for all our testing frameworks period, in-jvm dtest,
>> python dtest, and ccm. They're woefully under-documented IMO.
>>
>> On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
>>
>> To elaborate a bit on the steep learning curve point, when mentoring new
>> contributors on a couple of occasions I told them to "just write a python
>> dtest" because we had no idea on how to test that functionality on in-jvm
>> tests while the python dtest was fairly straightforward to implement (I
>> can't recall exactly what feature was it but I can dig if necessary).
>>
>> While we might be already familiar with the in-jvm dtest framework due to
>> our exposure to it, we shouldn't neglect that there is a significant
>> learning curve associated with it for new contributors which IMO is much
>> lower for pyhton dtests. So we should at least write extensive
>> documentation on how to use/modify in-jvm dtest framework before
>> deprecating python dtests.
>>
>> Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta <
>> pauloricard...@gmail.com> escreveu:
>>
>> > They use a separate implementation of instance initialization and thus
>> they test the test server rather than the real node.
>>
>> I also have this concern. When adding a new service on CASSANDRA-16789 we
>> had to explicitly modify the in-jvm dtest server to match the behavior from
>> the actual server [1] (this is just a minor example but I remember having
>> to do something similar on other tickets).
>>
>> Besides having a steep learning curve since users need to be familiar
>> with the in-jvm dtest framework in order to add new functionality not
>> supported by it, this is potentially unsafe, since the implementations can
>> diverge without being caught by tests.
>>
>> Is there any way we could avoid duplicating functionality on the test
>> server and use the same initialization code on in-jvm dtests?
>>
>> [1] -
>> http

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Brandon Williams]

> In fact there is a high learning curve to setup cassandra-dtest environment

I think this is fairly well documented:
https://github.com/apache/cassandra-dtest/blob/trunk/README.md

On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta  wrote:
>
> > I am curious about this comment.  When I first joined I learned jvm-dtest 
> > within an hour and started walking Repair code in a debugger (and this was 
> > way before the improvements that let us do things like nodetool)… python 
> > dtest took weeks to get working correctly (still having issues with the 
> > MBean library we use… so have to comment out error handling to get some 
> > tests to pass)….
>
> Thanks for sharing your perspective. In fact there is a high learning curve 
> to setup cassandra-dtest environment, but once it's working it's pretty 
> straightforward to test any existing or new functionality.
>
> I think with in-jvm dtests you don't have the hassle of setting up a 
> different environment and this is a great motivator to standardize on this 
> solution. The main difficulty I had was testing features not supported by the 
> framework, which require you to extend the framework. I don't recall having 
> to extend ccm/cassandra-dtest many times when working on new features.
>
> Perhaps this has improved recently and we no longer need to worry about 
> extending the framework or duplicating code when testing new functionality.
>
> Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova 
>  escreveu:
>>
>> One thing that we can add to docs is for people how to update the in-jvm 
>> framework and test their patches before asking for in-jvm api release. The 
>> assumption is those won’t be many updates needed I think, but it is good to 
>> be documented.
>>
>> On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:
>>>
>>> They use a separate implementation of instance initialization and thus they 
>>> test the test server rather than the real node.
>>>
>>>
>>> I think we can get rid of this by extending CassandraDaemon, just need to 
>>> add a few hooks to mock out gossip/internode/client (for cases where the 
>>> mocks are desired), and when mocks are not desired just run the real logic.
>>>
>>> Too many times I have had to make the 2 more in-line, and this is hard to 
>>> maintain… we should fix this and feel this is 100% fixable
>>>
>>> we shouldn't neglect that there is a significant learning curve associated 
>>> with it for new contributors which IMO is much lower for pyhton dtests
>>>
>>>
>>> I am curious about this comment.  When I first joined I learned jvm-dtest 
>>> within an hour and started walking Repair code in a debugger (and this was 
>>> way before the improvements that let us do things like nodetool)… python 
>>> dtest took weeks to get working correctly (still having issues with the 
>>> MBean library we use… so have to comment out error handling to get some 
>>> tests to pass)….
>>>
>>> Maybe we could have some example docs showing how to do the same in both 
>>> tools?  Honestly Cluster.build(3).withConfig(c -> 
>>> c.with(Feature.values())).start() matches 95% of python dtest tests (the 
>>> withConfig logic is a bit cryptic), so don’t think the docs would be too 
>>> much work
>>>
>>>
>>> On Mar 29, 2022, at 5:48 AM, Josh McKenzie  wrote:
>>>
>>> we should at least write extensive documentation on how to use/modify 
>>> in-jvm dtest framework before deprecating python dtests.
>>>
>>> We should have this for all our testing frameworks period, in-jvm dtest, 
>>> python dtest, and ccm. They're woefully under-documented IMO.
>>>
>>> On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
>>>
>>> To elaborate a bit on the steep learning curve point, when mentoring new 
>>> contributors on a couple of occasions I told them to "just write a python 
>>> dtest" because we had no idea on how to test that functionality on in-jvm 
>>> tests while the python dtest was fairly straightforward to implement (I 
>>> can't recall exactly what feature was it but I can dig if necessary).
>>>
>>> While we might be already familiar with the in-jvm dtest framework due to 
>>> our exposure to it, we shouldn't neglect that there is a significant 
>>> learning curve associated with it for new contributors which IMO is much 
>>> lower for pyhton dtests. So we should at least write extensive 
>>> documentation on how to use/modify in-jvm dtest framework before 
>>> deprecating python dtests.
>>>
>>> Em ter., 29 de mar. de 2022 às 06:58, Paulo Motta 
>>>  escreveu:
>>>
>>> > They use a separate implementation of instance initialization and thus 
>>> > they test the test server rather than the real node.
>>>
>>> I also have this concern. When adding a new service on CASSANDRA-16789 we 
>>> had to explicitly modify the in-jvm dtest server to match the behavior from 
>>> the actual server [1] (this is just a minor example but I remember having 
>>> to do something similar on other tickets).
>>>
>>> Besides having a steep learning curve since users need to be familia

Re: [DISCUSS] Should we deprecate / freeze python dtests

[bened...@apache.org]

It often does not work. I can attest to many wasted weeks, on some environments 
never getting them to work.

They happen to work right now for me, though.

I think the learning curve thing is a bit of a distraction, personally. I have 
always found python dtests hard to work with, both developing against and 
running, so their learning curve for me is going on 10 years. Some folk may be 
more comfortable with python dtests due to their familiarity with python, ccm 
or other tooling, but that is a different matter.

Looking at git, most contributors to python dtests are contributors to in-jvm 
dtests, and the latter have received 20x as many net code contributions over 
the past year.

I think it’s quite justified to just say in-jvm dtests are simply better to 
work with, and already better and more widely used despite their youth, 
whatever their remaining teething problems.

I vote we immediately discontinue python dtest development, and discontinue 
running python dtests pre-commit, retaining them for releases only. This will 
provide the necessary impetus to polish off any last remaining gaps, without 
reducing coverage.

From: Brandon Williams 
Date: Tuesday, 29 March 2022 at 23:42
To: dev 
Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
> In fact there is a high learning curve to setup cassandra-dtest environment

I think this is fairly well documented:
https://github.com/apache/cassandra-dtest/blob/trunk/README.md

On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta  wrote:
>
> > I am curious about this comment.  When I first joined I learned jvm-dtest 
> > within an hour and started walking Repair code in a debugger (and this was 
> > way before the improvements that let us do things like nodetool)… python 
> > dtest took weeks to get working correctly (still having issues with the 
> > MBean library we use… so have to comment out error handling to get some 
> > tests to pass)….
>
> Thanks for sharing your perspective. In fact there is a high learning curve 
> to setup cassandra-dtest environment, but once it's working it's pretty 
> straightforward to test any existing or new functionality.
>
> I think with in-jvm dtests you don't have the hassle of setting up a 
> different environment and this is a great motivator to standardize on this 
> solution. The main difficulty I had was testing features not supported by the 
> framework, which require you to extend the framework. I don't recall having 
> to extend ccm/cassandra-dtest many times when working on new features.
>
> Perhaps this has improved recently and we no longer need to worry about 
> extending the framework or duplicating code when testing new functionality.
>
> Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova 
>  escreveu:
>>
>> One thing that we can add to docs is for people how to update the in-jvm 
>> framework and test their patches before asking for in-jvm api release. The 
>> assumption is those won’t be many updates needed I think, but it is good to 
>> be documented.
>>
>> On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:
>>>
>>> They use a separate implementation of instance initialization and thus they 
>>> test the test server rather than the real node.
>>>
>>>
>>> I think we can get rid of this by extending CassandraDaemon, just need to 
>>> add a few hooks to mock out gossip/internode/client (for cases where the 
>>> mocks are desired), and when mocks are not desired just run the real logic.
>>>
>>> Too many times I have had to make the 2 more in-line, and this is hard to 
>>> maintain… we should fix this and feel this is 100% fixable
>>>
>>> we shouldn't neglect that there is a significant learning curve associated 
>>> with it for new contributors which IMO is much lower for pyhton dtests
>>>
>>>
>>> I am curious about this comment.  When I first joined I learned jvm-dtest 
>>> within an hour and started walking Repair code in a debugger (and this was 
>>> way before the improvements that let us do things like nodetool)… python 
>>> dtest took weeks to get working correctly (still having issues with the 
>>> MBean library we use… so have to comment out error handling to get some 
>>> tests to pass)….
>>>
>>> Maybe we could have some example docs showing how to do the same in both 
>>> tools?  Honestly Cluster.build(3).withConfig(c -> 
>>> c.with(Feature.values())).start() matches 95% of python dtest tests (the 
>>> withConfig logic is a bit cryptic), so don’t think the docs would be too 
>>> much work
>>>
>>>
>>> On Mar 29, 2022, at 5:48 AM, Josh McKenzie  wrote:
>>>
>>> we should at least write extensive documentation on how to use/modify 
>>> in-jvm dtest framework before deprecating python dtests.
>>>
>>> We should have this for all our testing frameworks period, in-jvm dtest, 
>>> python dtest, and ccm. They're woefully under-documented IMO.
>>>
>>> On Tue, Mar 29, 2022, at 6:11 AM, Paulo Motta wrote:
>>>
>>> To elaborate a bit on the steep learning curve point, when mentoring new 
>>> contribut

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Paulo Motta]

I support deprecating python dtests, as long as in-jvm dtests have feature
parity with python dtests, a well-defined path to reduce/eliminate code
duplication and basic documentation for newcomers to get up to speed with
writing in-jvm dtests and extending the framework.

Em ter., 29 de mar. de 2022 às 20:09, bened...@apache.org <
bened...@apache.org> escreveu:

> It often does not work. I can attest to many wasted weeks, on some
> environments never getting them to work.
>
>
>
> They happen to work right now for me, though.
>
>
>
> I think the learning curve thing is a bit of a distraction, personally. I
> have always found python dtests hard to work with, both developing against
> and running, so their learning curve for me is going on 10 years. Some folk
> may be more comfortable with python dtests due to their familiarity with
> python, ccm or other tooling, but that is a different matter.
>
>
>
> Looking at git, most contributors to python dtests are contributors to
> in-jvm dtests, and the latter have received 20x as many net code
> contributions over the past year.
>
>
>
> I think it’s quite justified to just say in-jvm dtests are simply better
> to work with, and already better and more widely used despite their youth,
> whatever their remaining teething problems.
>
>
>
> I vote we immediately discontinue python dtest development, and
> discontinue running python dtests pre-commit, retaining them for releases
> only. This will provide the necessary impetus to polish off any last
> remaining gaps, without reducing coverage.
>
>
>
> *From: *Brandon Williams 
> *Date: *Tuesday, 29 March 2022 at 23:42
> *To: *dev 
> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> > In fact there is a high learning curve to setup cassandra-dtest
> environment
>
> I think this is fairly well documented:
> https://github.com/apache/cassandra-dtest/blob/trunk/README.md
>
> On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta 
> wrote:
> >
> > > I am curious about this comment.  When I first joined I learned
> jvm-dtest within an hour and started walking Repair code in a debugger (and
> this was way before the improvements that let us do things like nodetool)…
> python dtest took weeks to get working correctly (still having issues with
> the MBean library we use… so have to comment out error handling to get some
> tests to pass)….
> >
> > Thanks for sharing your perspective. In fact there is a high learning
> curve to setup cassandra-dtest environment, but once it's working it's
> pretty straightforward to test any existing or new functionality.
> >
> > I think with in-jvm dtests you don't have the hassle of setting up a
> different environment and this is a great motivator to standardize on this
> solution. The main difficulty I had was testing features not supported by
> the framework, which require you to extend the framework. I don't recall
> having to extend ccm/cassandra-dtest many times when working on new
> features.
> >
> > Perhaps this has improved recently and we no longer need to worry about
> extending the framework or duplicating code when testing new functionality.
> >
> > Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova <
> e.dimitr...@gmail.com> escreveu:
> >>
> >> One thing that we can add to docs is for people how to update the
> in-jvm framework and test their patches before asking for in-jvm api
> release. The assumption is those won’t be many updates needed I think, but
> it is good to be documented.
> >>
> >> On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:
> >>>
> >>> They use a separate implementation of instance initialization and thus
> they test the test server rather than the real node.
> >>>
> >>>
> >>> I think we can get rid of this by extending CassandraDaemon, just need
> to add a few hooks to mock out gossip/internode/client (for cases where the
> mocks are desired), and when mocks are not desired just run the real logic.
> >>>
> >>> Too many times I have had to make the 2 more in-line, and this is hard
> to maintain… we should fix this and feel this is 100% fixable
> >>>
> >>> we shouldn't neglect that there is a significant learning curve
> associated with it for new contributors which IMO is much lower for pyhton
> dtests
> >>>
> >>>
> >>> I am curious about this comment.  When I first joined I learned
> jvm-dtest within an hour and started walking Repair code in a debugger (and
> this was way before the improvements that let us do things like nodetool)…
> python dtest took weeks to get working correctly (still having issues with
> the MBean library we use… so have to comment out error handling to get some
> tests to pass)….
> >>>
> >>> Maybe we could have some example docs showing how to do the same in
> both tools?  Honestly Cluster.build(3).withConfig(c ->
> c.with(Feature.values())).start() matches 95% of python dtest tests (the
> withConfig logic is a bit cryptic), so don’t think the docs would be too
> much work
> >>>
> >>>
> >>> On Mar 29, 2022, at 5:48 

Re: [DISCUSS] Should we deprecate / freeze python dtests

[bened...@apache.org]

> a well-defined path to reduce/eliminate code duplication and basic 
> documentation for newcomers to get up to speed with writing in-jvm dtests and 
> extending the framework

Are python tests much better here? If not, I do not see why these should be 
blockers for their deprecation.

Perfect feature parity also seems unnecessary - unless a missing feature is an 
active impediment. But as far as I know every missing feature is actively under 
development and can be expected very soon.

Let’s get this decision over and done with.


From: Paulo Motta 
Date: Wednesday, 30 March 2022 at 00:46
To: Cassandra DEV 
Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
I support deprecating python dtests, as long as in-jvm dtests have feature 
parity with python dtests, a well-defined path to reduce/eliminate code 
duplication and basic documentation for newcomers to get up to speed with 
writing in-jvm dtests and extending the framework.

Em ter., 29 de mar. de 2022 às 20:09, 
bened...@apache.org 
mailto:bened...@apache.org>> escreveu:
It often does not work. I can attest to many wasted weeks, on some environments 
never getting them to work.

They happen to work right now for me, though.

I think the learning curve thing is a bit of a distraction, personally. I have 
always found python dtests hard to work with, both developing against and 
running, so their learning curve for me is going on 10 years. Some folk may be 
more comfortable with python dtests due to their familiarity with python, ccm 
or other tooling, but that is a different matter.

Looking at git, most contributors to python dtests are contributors to in-jvm 
dtests, and the latter have received 20x as many net code contributions over 
the past year.

I think it’s quite justified to just say in-jvm dtests are simply better to 
work with, and already better and more widely used despite their youth, 
whatever their remaining teething problems.

I vote we immediately discontinue python dtest development, and discontinue 
running python dtests pre-commit, retaining them for releases only. This will 
provide the necessary impetus to polish off any last remaining gaps, without 
reducing coverage.

From: Brandon Williams mailto:dri...@gmail.com>>
Date: Tuesday, 29 March 2022 at 23:42
To: dev mailto:dev@cassandra.apache.org>>
Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
> In fact there is a high learning curve to setup cassandra-dtest environment

I think this is fairly well documented:
https://github.com/apache/cassandra-dtest/blob/trunk/README.md

On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta 
mailto:pauloricard...@gmail.com>> wrote:
>
> > I am curious about this comment.  When I first joined I learned jvm-dtest 
> > within an hour and started walking Repair code in a debugger (and this was 
> > way before the improvements that let us do things like nodetool)… python 
> > dtest took weeks to get working correctly (still having issues with the 
> > MBean library we use… so have to comment out error handling to get some 
> > tests to pass)….
>
> Thanks for sharing your perspective. In fact there is a high learning curve 
> to setup cassandra-dtest environment, but once it's working it's pretty 
> straightforward to test any existing or new functionality.
>
> I think with in-jvm dtests you don't have the hassle of setting up a 
> different environment and this is a great motivator to standardize on this 
> solution. The main difficulty I had was testing features not supported by the 
> framework, which require you to extend the framework. I don't recall having 
> to extend ccm/cassandra-dtest many times when working on new features.
>
> Perhaps this has improved recently and we no longer need to worry about 
> extending the framework or duplicating code when testing new functionality.
>
> Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova 
> mailto:e.dimitr...@gmail.com>> escreveu:
>>
>> One thing that we can add to docs is for people how to update the in-jvm 
>> framework and test their patches before asking for in-jvm api release. The 
>> assumption is those won’t be many updates needed I think, but it is good to 
>> be documented.
>>
>> On Tue, 29 Mar 2022 at 13:51, David Capwell 
>> mailto:dcapw...@apple.com>> wrote:
>>>
>>> They use a separate implementation of instance initialization and thus they 
>>> test the test server rather than the real node.
>>>
>>>
>>> I think we can get rid of this by extending CassandraDaemon, just need to 
>>> add a few hooks to mock out gossip/internode/client (for cases where the 
>>> mocks are desired), and when mocks are not desired just run the real logic.
>>>
>>> Too many times I have had to make the 2 more in-line, and this is hard to 
>>> maintain… we should fix this and feel this is 100% fixable
>>>
>>> we shouldn't neglect that there is a significant learning curve associated 
>>> with it for new contributors which IMO is much lower for pyhton dt

[DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Erick Ramirez]

I wanted to bring this up again from Benjamin's original thread
. I agree
with Melissa and I really think there's a lot of value in creating a
company page on LinkedIn in addition to the "C* Community" group. There is
a bigger potential for us from a marketing perspective to promote Cassandra
to a wider audience with a company page. For what it's worth, Apache Pulsar
 already does this. Off the
top of my head, here are some notable points:

LinkedIn company page:

   - ✅ users can "follow" the page and see posts in their feed
   - ✅ users can @-tag Cassandra in their own posts
   - ✅ reach a wider network on LinkedIn
   - ✅ promote new contributors publicly

LinkedIn group:

   - ✅ great for building a community
   - ✅ deeper discussion on topics
   - 👎 users need to join the group
   - 👎 posts are only visible to members

Is there an appetite from the project to pursue this? Cheers!

On Thu, 10 Mar 2022 at 06:06, Melissa Logan  wrote:

> I agree there should be an official LinkedIn page for the project hosted
> by the community. It's an easy way for people to stay current.
>
> If the goal of the new LinkedIn page is to publicly and broadly share what
> the Cassandra community is doing, one solution would be to change the new
> Cassandra page from a "group" page to a "company" page.
>
> Company pages show all posts publicly by default, and admins don't have to
> manage requests to join. Anyone can "follow" the page and see/share the
> posts -- while only allowing community admins to publish. This would also
> require less care and feeding from community admins. (What I don't know if
> it's easy to "convert" a group page to company or if it requires starting
> from scratch.)
>
> Then, admins of the existing "group" page could repost any/all items from
> the community page to keep people informed.
>
> This solution could help both pages achieve their goals of spreading the
> word about Cassandra.
>
> --
> Melissa Logan (she/her)
> Principal, Constantia.io
> LinkedIn  | Twitter
> 
>

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Paulo Motta]

I was unpleasantly surprised to find out that Linkedin group posts are not
visible outside of the group, which greatly reduces post visibility. I
originally supported the group creation because I thought the posts would
be visible outside the group but this doesn't seem to be the case.

The only thing that bothers me about having a company page is that the
project is not technically a company, but if this is not breaking any
Linkedin ToS and there is precedence in other Apache projects I think it
makes sense to create the company page to give more visibility to community
posts.

I just don't see much value in keeping the group if we decide to create the
company page, since we may risk duplicating effort and attention. I don't
think Linkedin is the place for technical discussions since we have other
forums for that, I see it more as a marketing channel.

Em ter., 29 de mar. de 2022 às 21:41, Erick Ramirez <
erickramire...@apache.org> escreveu:

> I wanted to bring this up again from Benjamin's original thread
> . I
> agree with Melissa and I really think there's a lot of value in creating a
> company page on LinkedIn in addition to the "C* Community" group. There is
> a bigger potential for us from a marketing perspective to promote Cassandra
> to a wider audience with a company page. For what it's worth, Apache
> Pulsar  already does
> this. Off the top of my head, here are some notable points:
>
> LinkedIn company page:
>
>- ✅ users can "follow" the page and see posts in their feed
>- ✅ users can @-tag Cassandra in their own posts
>- ✅ reach a wider network on LinkedIn
>- ✅ promote new contributors publicly
>
> LinkedIn group:
>
>- ✅ great for building a community
>- ✅ deeper discussion on topics
>- 👎 users need to join the group
>- 👎 posts are only visible to members
>
> Is there an appetite from the project to pursue this? Cheers!
>
> On Thu, 10 Mar 2022 at 06:06, Melissa Logan  wrote:
>
>> I agree there should be an official LinkedIn page for the project hosted
>> by the community. It's an easy way for people to stay current.
>>
>> If the goal of the new LinkedIn page is to publicly and broadly share
>> what the Cassandra community is doing, one solution would be to change the
>> new Cassandra page from a "group" page to a "company" page.
>>
>> Company pages show all posts publicly by default, and admins don't have
>> to manage requests to join. Anyone can "follow" the page and see/share the
>> posts -- while only allowing community admins to publish. This would also
>> require less care and feeding from community admins. (What I don't know if
>> it's easy to "convert" a group page to company or if it requires starting
>> from scratch.)
>>
>> Then, admins of the existing "group" page could repost any/all items from
>> the community page to keep people informed.
>>
>> This solution could help both pages achieve their goals of spreading the
>> word about Cassandra.
>>
>> --
>> Melissa Logan (she/her)
>> Principal, Constantia.io
>> LinkedIn  | Twitter
>> 
>>
>