[Autoscaler] gcp parallel terminate nodes

[Dan-Yeh]

Why are these changes needed?

ray down takes a lot of time when using GCPNodeProvider as stated in #26239 because GCPNodeProvider uses the serial implementation of terminate_nodes from parent class NodeProvider and also uses a coarse lock in its terminate_node which prevents executing it in a concurrent fashion (not really sure coz I'm new to this).

• add threadpoolexecutor in GCPNodeProvider.terminate_nodes for parallelization execution of terminate_node
• use fine-grained locks which assign one RLock per node_id
• add unit_tests

why not go with the suggestions(batch apis and non-blocking version of terminate_node) mentioned in #26239?
As a novice, I think both solutions would break Liskov Substitute Principle, and also for those who already used terminate_node(s) would need to add await.

Related issue number

#26239

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[wuisawesome]

Thanks for the contribution @Dan-Yeh!

I think the overall aim of the PR (parallelize node deletion) makes sense to me at a high level.

My main concern is around the locking.

I see how having terminate_node acquire a global lock would cause contention and effectively lead to serializing the requests.

With this new locking scheme, I'm concerned that we're introducing race condition around the creation/deletion of nodes. Those operations seem like they inherently require a global lock.

I think a simple/safe way we could do this right now could be to keep the global lock and restructure the termination code like

class NodeProvider:
  def _thread_unsafe_terminate_node(self, node_id):
     # Assumes the global lock is held for the duration of this operation. The lock may be held by a different thread as is the case in `terminate_nodes()`.
    ...

  def terminate_node(self, node_id):
    with self.lock:
      self._thread_unsafe_terminate_node(node_id)

  def terminate_nodes(self, node_ids):
    with self.lock, concurrent.futures.ThreadPoolExecutor() as executor:
      executor.map(self._thread_unsafe_terminate_node, node_ids)

If you want to do the fine grained locking, I think we would need two phase locking. Something like

1. Acquire global lock
2. Add node id
3. Acquire per-node locks
4. Release global lock

and termination

1. Acquire global lock
2. Acquire per-node lock
3. delete global entry
4. release global lock
5. release local lock

Let me know if that makes sense to you

[Dan-Yeh]

Thanks for the suggestions! I think I would go with simple/safe way because it is hard to think about all possible scenarios for race condition or dead lock.

[wuisawesome]

Thanks!

[wuisawesome]

@Dan-Yeh do you mind rebasing, that should make the ci failures go away, and then i think we're good to merge.

[Dan-Yeh]

Sure.
Just did it, hope it's alright coz it's my first time using rebase :)

[wuisawesome]

Whelp our CI has quite a few broken tests at the moment, but none of the test failures look related to this PR, so I'll merge now.

Thanks @Dan-Yeh for the contribution!