[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429788#comment-17429788
]
Ekaterina Dimitrova commented on CASSANDRA-17043:
-------------------------------------------------
{quote}I understand that the parallelisms for the regular test jobs are based
on the number of tests in that job, while the parallelism for the multiplexer
jobs should be based on the number of repetitions, which defaults to 100.
{quote}
Parallelism leads to shorter time for tests execution so what I meant Is that
for the regular job run of all unit tests, python dtests etc we made extensive
testing to come up with a good tradeoff between time to run them and used
CircleCI credits. We can't really make the same testing to check in a loop
every test how much time it needs but we can approximate in general what would
be an expected time to run for 100 tests of certain type on top of the minimum
requirements for resources for those tests to run. About LOWRES config - there
is a limit for the free tier anyway so I guess people will get limited anyway.
And my understanding for the HIGHRES configuration is that it just exercises
all resources and gets the quickest CI runs possible.
In that sense it makes sense to me to raise the parallelism for the MIDRES
multiplexer for the upgrade in-jvm tests for example. Why ? Because the whole
suite is 10-20 test classes, but the default run in a loop which I would assume
most people will run is 100. So if we generalize this means to me 10 times more
time for execution if we think that most tests need similar amount of time to
run(do they?).
The proposed changes look good to me in general but we might need to raise the
python dtests parallelism as I know they require a lot of resources. Can we run
some of the classes to see how that will go, for a direction? Does this make
sense?
> CircleCI dtest multiplexer with MIDRES needs more resources
> -----------------------------------------------------------
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
