Block tablet draining when tablet load balancing is disabled by user's requets about scylladb

[bhalevy]

I vote for failing draining since the cause is due to an admin operation, rather than an automatic process that we know it would end in a timely manner.

[bhalevy]

@tgrabiec did you start working on this?
If not, @tchaikov can own it in conjunction with #16437

[tgrabiec]

@tgrabiec did you start working on this?

No

If not, @tchaikov can own it in conjunction with #16437

Sounds good.

[tgrabiec]

I vote for failing draining since the cause is due to an admin operation, rather than an automatic process that we know it would end in a timely manner.

That depends on which systems will call this disabling. If it will be called by a process in the cloud which is independent of topology operations then it could cause disruptions.

What's the downside of blocking? It seems safer in that regard.

[bhalevy]

I vote for failing draining since the cause is due to an admin operation, rather than an automatic process that we know it would end in a timely manner.

That depends on which systems will call this disabling. If it will be called by a process in the cloud which is independent of topology operations then it could cause disruptions.

What's the downside of blocking? It seems safer in that regard.

The downside is that the request may block indefinitely.
For example, if the admin disabled migrations due to some reason, like they forgot about it, or maybe there was a bug and disabling migrations was needed as a workaround.
We can have a --force flag to bypass this check.

[bhalevy]

@avikivity said on today's call that this wouldn't be needed as the admin should just avoid topology changes if they want the tablets map / describring results to be stable.

[bhalevy]

Let's close then, and reopen if we convince ourselves this is required.

[tchaikov]

thanks Benny!