[ 
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416074#comment-17416074
 ] 

Berenguer Blasi commented on CASSANDRA-16951:
---------------------------------------------

- Yes the assumption is the alphabetical order as that is pytest default and 
what I've seen son far.
- Yes if you add a new test and you want it to join the 'reuse string' you have 
to annotate it appropriately depending on where you place it. 
- The first one sees a reuse cluster being requested, it's not there so creates 
a new one. The next test having 'newCluster' will _not_ reuse it and create a 
new one as this is what you're asking explicitly. That is useful if you change 
node config i.e. (or shg else) and you want to force a new cluster.
- There are few isolation guarantees. The ones I could think of: nodes are 
alive, KS cleanup, I left byteman injections cleanup and configs compare as a 
TODO, etc. But ultimately it is a best effort basis that I hope covers 90% of 
cases. It is the author who knows if he has done sthg so crazy that has left 
nodes broken. 

And yes if you execute tests in the wrong order you can break things. The only 
hole I am aware of is executing 2 tests from 2 different strings from the same 
class. But I haven't seen this happening. Class level annotation would prevent 
that iiuc.

> Dtest cluster reusage
> ---------------------
>
>                 Key: CASSANDRA-16951
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Test/dtest/python
>            Reporter: Berenguer Blasi
>            Assignee: Berenguer Blasi
>            Priority: Normal
>             Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent 
> restarting nodes in between test methods. Not all of them, but many seem 
> could benefit form reusing a common cluster sparing the restarts. Obviously 
> that is not the case for tests that manipulate the nodes itself during the 
> test. The ones that follow a setup node/do test seem to benefit greatly in 
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to 
> 25m. But taking a 5m shave and considering it will probably get ran * 
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m 
> cut. That should be a nice reduction in CI usage. Unfortunately run time will 
> mostly remain the same until we have a majority of tests reusing nodes as the 
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with 
> {{@reuse_cluster(new_cluster=True)}} and the following ones with 
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using 
> the annotation at any test method and it will start a new one.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to