In some scenarios, the drain operation can take longer than 30 seconds (the configured driver requesttimetout). Ideally, the call to drain a node would be asynchronous and a new endpoint could be added to poll the status of the drain. However, it would maybe be beneficial to simply adding a "slow" driver execution profile for this, and change the implementation of drain to make a CQL query with the slow profile enabled (see the Java driver docs for more details on execution profiles).
This "slow" execution profile could also be used for other Management API functions that could take longer than 30 seconds to complete under the hood, with the benefit of being able to make the change to management API and not having to make changes on down-stream projects (like cass-operator).
In some scenarios, the drain operation can take longer than 30 seconds (the configured driver requesttimetout). Ideally, the call to drain a node would be asynchronous and a new endpoint could be added to poll the status of the drain. However, it would maybe be beneficial to simply adding a "slow" driver execution profile for this, and change the implementation of drain to make a CQL query with the slow profile enabled (see the Java driver docs for more details on execution profiles).
This "slow" execution profile could also be used for other Management API functions that could take longer than 30 seconds to complete under the hood, with the benefit of being able to make the change to management API and not having to make changes on down-stream projects (like cass-operator).