Roy Dahan
Roy Dahan
I can move this issue to scylla-manager and @tzach can define there if increasing the timeout is needed and by how much.
Actually, I can't move, I think I don't have enough permissions there.
I'm not sure if it's a transient issue that SCT should ignore or a real problem with manager / scylla. I have a job that reproduces the issue quite consistently....
Still happens: https://argus.scylladb.com/test/f1ff65fd-8324-4264-8d28-8c7122fca836/runs?additionalRuns[]=5986619f-8479-4267-a92f-19c6b604f84b
Should we have an assignee here?
I don't know why, but the option of "Transfer Issue" isn't available for Issues in this repo.
It can't be the logs because it happens only on one node and the pattern is that space is going up but also down. @ilya-rarov please correlate the used space...
@ilya-rarov it doesn't help just throwing more and more information from reproducers. We need to find an exact reproducer. It seems like the reproducer is the backup nemesis, not repair....
I don't know. Maybe the manager does its operations sequentially on the nodes and not in parallel. Another way to debug it is to keep the cluster alive and check...