disrupt_add_remove_mv nemesis enhancement

[timtimb0t]

disrupt_add_remove_mv nemesis often fails with the following error:

Traceback (most recent call last):
  File "/home/ubuntu/scylla-cluster-tests/sdcm/nemesis.py", line 5447, in wrapper
    result = method(*args[1:], **kwargs)
  File "/home/ubuntu/scylla-cluster-tests/sdcm/nemesis.py", line 5115, in disrupt_add_remove_mv
    drop_materialized_view(session, ks_name, view_name)
  File "/home/ubuntu/scylla-cluster-tests/sdcm/utils/nemesis_utils/indexes.py", line 125, in drop_materialized_view
    session.execute(SimpleStatement(f'DROP MATERIALIZED VIEW {ks}.{view_name}'), timeout=300)
  File "/home/ubuntu/scylla-cluster-tests/sdcm/utils/common.py", line 1318, in execute_verbose
    return execute_orig(*args, **kwargs)
  File "cassandra/cluster.py", line 2729, in cassandra.cluster.Session.execute
  File "cassandra/cluster.py", line 5120, in cassandra.cluster.ResponseFuture.result
cassandra.OperationTimedOut: errors={'10.142.0.227:9042': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.142.0.227:9042

But in fact the drop index operation often is successful, seems like timeouts on SCT side should be adjusted

[soyacz]

does this statement support 'using timeout'?
besides, shouldn't it be fast operation?

[timtimb0t]

does this statement support 'using timeout'? besides, shouldn't it be fast operation?

I'm not sure regarding the 'using timeout' I'll investigate it a little bit more but it definitely can take a while

[soyacz]

does this statement support 'using timeout'? besides, shouldn't it be fast operation?

I'm not sure regarding the 'using timeout' I'll investigate it a little bit more but it definitely can take a while

see, that this is not "SCT side timeout" rather Scylla's one