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
th.
>
>
>
>
>
> From: Paulo Motta mailto:pauloricard...@gmail.com>>
> Date: Wednesday, 30 March 2022 at 00:46
> To: Cassandra DEV mailto:dev@cassandra.apache.org>>
> Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> I support
.
>>> >>>
>>> >>> 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
>>> >&
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] Sh
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
s 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: *
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
>> é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 limi
gt;
>>
>> 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.
>>
>
> - 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 alread
>>
>> - 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 no
> 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
A-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
ultiple
>> 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 ug
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
>
&
o: 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 rathe
f
> 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 d
.
>>
>>
>> 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-
annot 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
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
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
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
22 matches
Mail list logo
