[SOLR-6981] bin/solr should have a delete action to complement the create action

• Type: New Feature
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Fix Version/s: 5.0, 6.0
• Component/s: scripts and tools
• Assignee: Timothy Potter
• Reporter: Timothy Potter
• Created: 14/Jan/15 21:06
• Updated: 09/May/16 18:45
• Resolved: 16/Jan/15 06:41

Description

In SOLR-6952, we changed the create_collection logic to create a copy of a configset in ZooKeeper by default, i.e. if you do bin/solr create -c foo then then the server/solr/configsets/data_driven_schema_configs directory is uploaded to ZK as /configs/foo ... Since it is data driven, the managed schema starts to change as docs flow in ... good so far ... now the user decides to delete the foo collection and re-create it. The delete collection action leaves the /configs/foo directory in ZK and the create action in bin/solr does not overwrite existing files in ZooKeeper. So something very subtle happens, the previous data-driven changes are still in effect, which will be quite confusing for new users who think the delete action removed the configs.

For now, I think the bin/solr script should handle this on the delete side by:

1) checking to make sure the config is not being used by any other collection
2) delete the /configs/foo after deleting the collection

If the check for #1 fails, then the delete will proceed with a simple WARNING that the configs are shared and will not be deleted by this action.

Looking ahead, we probably want to deal with this copying of configsets and then handling the deletes correctly in the collections API, i.e. right now, the smarts can live in the bin/solr script and SolrCLI but the long-term solution should be to move those smarts into the CREATE and DELETE actions of the Collections API. We also should think about making the concept of a "shared" configuration directory more explicit.