SOLR-18370: remove the ADDROLE/REMOVEROLE Overseer Roles API - #4772
SOLR-18370: remove the ADDROLE/REMOVEROLE Overseer Roles API#4772serhiy-bzhezytskyy wants to merge 3 commits into
Conversation
Removes CollectionsHandler's ADDROLE_OP/REMOVEROLE_OP, ClusterAPI's v2 add-role/remove-role commands, ClusterStatus.ROLES_PROP, CollectionAdminRequest. addRole/removeRole, and the roles.json ZK node. Replacement is Node Roles (-Dsolr.node.roles), already in place. The internal re-prioritization signal (a node starting as overseer:preferred nudges the Overseer) reused the ADDROLE enum value and an OverseerRoleCmd class purely because they already existed. Renamed both (REPRIORITIZE_OVERSEER, OverseerPrioritizationCmd) instead of keeping a role-shaped name that needed a paragraph to explain. Orphaned by the removal, also deleted: CollectionsHandler.KNOWN_ROLES, ClusterAPI.RoleInfo, CollectionAdminParams.ROLE (0 remaining refs anywhere, confirmed each with a fresh grep after the previous deletion). Two ADDROLE-only tests replaced with one test of the actual invariant (a preferred node takes over without waiting for the current Overseer to restart); RollingRestartTest deleted wholesale (its single @test was 100% ADDROLE-dependent). Ref-guide updated to match: removed the ADDROLE/REMOVEROLE sections from cluster-node-management.adoc (including a stale roles response field in the CLUSTERSTATUS example), added major-changes-in-solr-11.adoc. AI-assisted (Claude Sonnet 5)
github-actions
Bot
added
documentation
CI's validateLogCalls caught it: switching the ADDROLE-era log.warn to log.info left props.jsonStr() unguarded, an expensive call that would now run even when INFO logging is disabled. Wrapped in isInfoEnabled(), matching the pattern already used elsewhere in this file. AI-assisted (Claude Sonnet 5)
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
| package org.apache.solr.cloud.api.collections; |
There was a problem hiding this comment.
Can you give me some context on why we had to add this whole class? This looks like a big add, is it because something was missed when we moved to the node roles earlier?
There was a problem hiding this comment.
Not a big add -- it's a smaller replacement for the deleted OverseerRoleCmd (64 lines vs. 128), not new functionality. The internal re-prioritization nudge (a node starting as overseer:preferred pokes the Overseer to re-run prioritization) was already there -- it just piggybacked on the ADDROLE enum value and OverseerRoleCmd class purely because they already existed, since ADDROLE/REMOVEROLE were the only overseer-related messages at the time. Now that those are gone, the nudge needed an honest name of its own instead of a role-shaped one that needed a paragraph to explain -- hence REPRIORITIZE_OVERSEER/OverseerPrioritizationCmd, stripped of the roles.json persistence logic that went away with ADDROLE/REMOVEROLE.
AI-assisted (Claude Sonnet 5)
| @BeforeClass | ||
| public static void setupCluster() throws Exception { | ||
| configureCluster(4).addConfig("conf", configset("cloud-minimal")).configure(); | ||
| // SolrCloudTestCase randomises solr.cloud.overseer.enabled; this test is about the Overseer |
There was a problem hiding this comment.
Yes -- SolrCloudTestCase randomizes solr.cloud.overseer.enabled across runs, and the old testOverseerRole() silently no-op'd (early return) whenever a run landed on distributed-Collection-API mode. Since this test is specifically about Overseer election, .withOverseer(true) pins it so it actually exercises the behavior every run instead of ~50% of the time.
AI-assisted (Claude Sonnet 5)
|
@HoustonPutman @dsmiley there is some additional code in this that maybe would be of interest to you to review, it's not just a stright removal. |
…rseer-roles-api-fresh
2 participants
https://issues.apache.org/jira/browse/SOLR-18370
Removes the ADDROLE/REMOVEROLE Overseer Roles API. Replacement is Node Roles (
-Dsolr.node.roles), already in place.CollectionsHandlerADDROLE_OP/REMOVEROLE_OP,ClusterAPI's v2 add-role/remove-role,ClusterStatus.ROLES_PROP,CollectionAdminRequest.addRole/removeRole, theroles.jsonZK nodeCollectionsHandler.KNOWN_ROLES,ClusterAPI.RoleInfo,CollectionAdminParams.ROLE-- 0 remaining refs anywhereADDROLEenum value and anOverseerRoleCmdclass only because they already existed. Renamed both (REPRIORITIZE_OVERSEER,OverseerPrioritizationCmd) rather than keep a role-shaped name that needed a paragraph to explainRollingRestartTestdeleted -- its one@Testwas 100% ADDROLE-only.OverseerRolesTest's two ADDROLE tests replaced with one test of the actual invariant: a preferred node takes over without waiting for the current Overseer to restartcluster-node-management.adoc(incl. a stalerolesfield in the CLUSTERSTATUS example), addedmajor-changes-in-solr-11.adoc33 tests, 0 failures. Merge-simulated against all 4 open PRs sharing a file with this one (#4767/#4768/#4769/#4770) together -- applies clean.
AI-assisted (Claude Sonnet 5)