[SOLR-16543] Simplify ConfigSet processing; remove parts of DistributedCollectionConfigSetCommandRunner

• Type: Task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: David Smiley
• Created: 10/Nov/22 02:18
• Updated: 25/Jan/23 16:16

Description

SOLR-16542 calls for ConfigSet commands to internally only run via DistributedCollectionConfigSetCommandRunner and not OverseerConfigSetMessageHandler which won't exist henceforth. Given that the ConfigSet API is extremely simple CRUD implemented on top of ZooKeeper (which has its own CRUD of course) simply without any exotic requirements (as found for collection processing), the complexity in DistributedCollectionConfigSetCommandRunner is unwarranted for ConfigSets. Removing it will allow significant simplifications between the API surface and the actual execution from code maintainability/readability standpoint – removing a layer of indirection. The processing need not occur in a dedicated executor and need not support async. Special locks are probably needless. When sending multiple files as part of uploading a ConfigSet, it can be combined into a ZK multi-op, thus appear atomically, which is an improvement in atomicity than we have today when a configSet is being updated and a collection is pointing at it.

RE locks: ConfigSet downloading might see a partially updated ConfigSet if multiple API modifications come into a ConfigSet, interleaving with the reading, but that seems too exotic to justify a lock. As it is, a collection reading a ConfigSet does it a file at a time, thus would have the same issue and no lock saves us from this today. Users concerned about lack of atomicity for certain scenarios when updating a ConfigSet could simply not do that – create new ones instead, and point collections at the new one.

Issue Links

• requires: SOLR-16542 Remove OverseerConfigSetMessageHandler; always do distributed mode