[
https://issues.apache.org/jira/browse/SOLR-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-8008:
------------------------------------
Assignee: Erick Erickson
> bin/solr should delete configset if collection creation fails and no other
> collection references it
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-8008
> URL: https://issues.apache.org/jira/browse/SOLR-8008
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> A user's list question prompted this, and at least two other devs hit it so
> I'm not imagining things.
> The bin/solr script (and SolrCLI) for create_collection uploads the config
> set automatically if (and only if) it's not in ZK already. But...
> Let's say I have a problem with my config files (syntax error, deprecated
> options, whatever) that prevents the collection from being created. It gets
> pretty confusing to correct the configs and try to create your collection
> again and have it fail for the same reason because the configs weren't
> re-uploaded to ZK.
> I can think of at least three+ options:
> 1> delete the configsets from ZK in collection failure case if (and only if)
> it isn't referenced by another collection. I like this one as, from a user's
> perspective, it's least confusing. I see my collection creation failed
> because of a problem in my configs. I correct the configs and do the exact
> same operation again and it succeeds.
> 1a> provide a "force configset update" option for create_collection. This
> one's easiest I think.
> 2> Provide an upload_configset option that overwrites an existing configset.
> Perhaps with a -force flag to insure it's done intentionally.
> 3> make the delete collection option remove a configset named identically to
> the collection even if the collection doesn't exist.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
