[
https://issues.apache.org/jira/browse/SOLR-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733800#comment-14733800
]
Mark Miller commented on SOLR-8008:
-----------------------------------
{quote}I'm not a fan of it either, just getting all the options out there. I'll
quibble a little bit here, the
options in bin/solr already mess with config sets when messing with collections
by uploading
the specified configset if it's not there already when creating a
collection.{quote}
Bootstrapping a collection by auto uploading a config set for it is one thing.
I have no problem with that. Automatically deleting a shared resource like that
when messing with another resource is very different I think.
bq. And there's no command in bin/solr that lets you upload configsets
separately, perhaps there should be.
Agreed that it should be easy to upload a config set again. Making the start
script also able to handle config seems like the right approach to me. A tool
that does one and only implicitly the other is going to have a lot of problems.
> 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
> Reporter: Erick Erickson
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
