Israel Fruchter

the last report from @vponomaryov is something that is reproducible running it now with c-s debug enabled https://argus.scylladb.com/test/7748483c-dd44-4306-9e69-97c97214f482/runs?additionalRuns[]=a242eed1-bb86-48e4-b27b-aec40cbb23db

> To expedite fixing the problem, @Bouncheck will try: > > * Rerunning the job with higher timeout (rather than the current +5%) this can be changed in: https://github.com/scylladb/scylla-cluster-tests/blob/master/sdcm/stress_thread.py#L365 >...

> I have trouble understanding some of the logs. > For example in this run: https://jenkins.scylladb.com/job/scylla-5.4/job/longevity/job/longevity-10gb-3h-gce-test/9/ > In the `loader-set-3e9f3337/cassandra-stress-write-l0-c0-k1-d967395a-8701-4848-9d4c-5225146c1a96.log` > I can see the following lines: > ``` >...

@dkropachev any idea how to push this on forward, it's happening on almost daily basis on SCT short longevity

I'll share the example of how to get an actual version sting out of CCM, without running a version

so basically we need to run this with the version (it would download and cache it, for next cluster it create) ```bash ❯ ccm create get_version -n 1 --scylla --version...

It's depend on this CCM fix, to work without starting a node: https://github.com/scylladb/scylla-ccm/pull/458

> @k0machi isn't this already fixed in matrix tests? No, patched and hardcoded it to some number for now.

beside the docs, I think a warning of misuse might be in order...

@amnonh is there anything we can do with this one ? in any case we still need to clone this repo, it's slows it down considerably