Search before asking
Description
Task Overview:
Currently, Admin.addServerTag() and Admin.removeServerTag() only support specifying tablet servers by their server IDs. This task introduces two new overloaded methods that allow users to target all tablet servers belonging to a specific rack in a single call.
Purpose:
In production environments, the rack attribute of a ServerNode typically represents a physical machine (or a physical rack of machines). A common operational scenario is decommissioning a physical host — which may run multiple tablet servers — and marking all of them as PERMANENT_OFFLINE or TEMPORARY_OFFLINE at once.
Without rack-based targeting, operators must:
- Call
Admin.getServerNodes() to retrieve all server nodes.
- Manually filter the results by the target rack.
- Extract the server IDs.
- Call
addServerTag() / removeServerTag() with those IDs.
This is repetitive, error-prone, and adds unnecessary boilerplate in automation scripts. A dedicated rack-based API makes the decommissioning workflow concise and intuitive.
Willingness to contribute
Search before asking
Description
Task Overview:
Currently,
Admin.addServerTag()andAdmin.removeServerTag()only support specifying tablet servers by their server IDs. This task introduces two new overloaded methods that allow users to target all tablet servers belonging to a specific rack in a single call.Purpose:
In production environments, the
rackattribute of aServerNodetypically represents a physical machine (or a physical rack of machines). A common operational scenario is decommissioning a physical host — which may run multiple tablet servers — and marking all of them asPERMANENT_OFFLINEorTEMPORARY_OFFLINEat once.Without rack-based targeting, operators must:
Admin.getServerNodes()to retrieve all server nodes.addServerTag()/removeServerTag()with those IDs.This is repetitive, error-prone, and adds unnecessary boilerplate in automation scripts. A dedicated rack-based API makes the decommissioning workflow concise and intuitive.
Willingness to contribute