[
https://issues.apache.org/jira/browse/SOLR-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733875#comment-14733875
]
Erick Erickson commented on SOLR-8008:
--------------------------------------
bq: A tool that does one and only implicitly the other is going to have a lot
of problems.
I think that crystalizes what I'm thinking. Personally I'd like both a
-overwriteConfig
option on the create _and_ a separate uploadConfig option, but then I'm not
writing
the code..
Hmmm, instead of an -overwriteConfig option, maybe require a confirmation if
you specify a configset when creating a collection and the configset is already
in ZK like "configuration set blahblahblah already exists in Zookeeper,
overwrite?". Actually I like this better than an overwrite flag, it doesn't
require the user to do anything different the second time they create a
collection than they did the first time. Requiring an overwrite flag would
still be confusing because there's no way for them to know the fixed configs
didn't get sent to ZK, leaving them puzzled why the fixes didn't "take".
Or even just error out on create collection when the configset already exists
with an appropriate message. We'd need an uploadconfig command in that case
though.
I think there should be an uploadConfig separately too...
> 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]
