[ 
https://issues.apache.org/jira/browse/SOLR-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729623#comment-14729623
 ] 

Erick Erickson commented on SOLR-8008:
--------------------------------------

bq: I don't like 3. These are two separate things, messing with collections 
should not mess with config sets.

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. 
The argument that
create_collection _shouldn't_ do this could certainly be made.

bq: Upload configs should already overwrite? It doesn't?

Yes it does, but it requires you to go outside the bin/solr script and use 
zkcli directly which is an extra complication IMO. Ideally I'd like the users 
to never need to know that zkcli exists. And there's no command in bin/solr 
that lets you upload configsets separately, perhaps there should be.

It's confusing that the process for a new user is
-bin/solr create_collection blah blah
>>create failed because of a bad config (in this particular case, 
    it looks like the user was trying to use a 4.x schema that had 
    deprecated options)
- fix the schema
-use the same create_collection call and it fails with the 
   same error b/c the fixed configset wasn't uploaded.

> 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]

Reply via email to