[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Epic Link: CASSANDRA-17276
> 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.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Patch Available (was: Review In Progress)
> 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.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Open (was: Patch Available)
> 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.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Review In Progress (was: Patch Available)
> 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.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Status: Patch Available (was: In Progress)
> 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.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Reviewers: Josh McKenzie
> 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.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16951:
Status: In Progress (was: Patch Available)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16951:
Test and Documentation Plan: See first comment in ticket
Status: Patch Available (was: In Progress)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16951:
Description:
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.
was:
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 ruse the cluster will be made. Stop using
the annotation at any test method and it will start a new one.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16951:
Description:
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 ruse the cluster will be made. Stop using
the annotation at any test method and it will start a new one.
was:
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.
> 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 ruse 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[ https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16951: Summary: Dtest cluster reusage (was: Dtest node reusage) > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
