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
ght
>> 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
>>
&
>
> - 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
s to the shared API project – some should be retained
> within the C* tree, with the API primarily serving as the shared API itself
> to ensure cross-version compatibility. However, this is far from a complete
> explanation of (or solution to) the problem.
>
>
>
>
>
>
d API itself to
ensure cross-version compatibility. However, this is far from a complete
explanation of (or solution to) the problem.
From: Josh McKenzie
Date: Monday, 14 March 2022 at 12:11
To: dev@cassandra.apache.org
Subject: [DISCUSS] Should we deprecate / freeze python dtests
I've be
I've been wrestling with the python dtests recently and that led to some
discussions with other contributors about whether we as a project should be
writing new tests in the python dtest framework or the in-jvm framework. This
discussion has come up tangentially on some other topics, including
23 matches
Mail list logo