[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249798#comment-16249798
]
Erick Erickson commented on SOLR-11624:
---------------------------------------
I'm -1 on both of these. Just because Solr created the configset does not mean
Solr controls its entire lifecycle, we even provide tools for changing the
configset! The naming is irrelevant. I'm assuming the SOLR_CONFSET bit
indicates that Solr created it. That does not mean it hasn't been modified.
This does not address the root problem: the current behavior _overwrites_ an
existing configset that I may have modified. I don't care how it was created,
this is the root problem that I'm -Integer.MAX_VALUE on.
Scenario
> I create collection EOE, SOLR_CONFIGSET.EOE is created by Solr
> I customize the configset.
> I create 3 more collections pointing to it.
> I drop and recreate collection EOE.
> my other three collections now use the default configset with who knows what
> consequences?
It's reasonable for users to drop and recreate a collection. It is also quite
common for users to have multiple collections point to the same config set.
Deleting (or overwriting) a configset _for_ them when they didn't direct Solr
to is a problem.
I really don't see what the value is in making this so complex, the fix is
simple. Just stop overwriting the configset if it already exists. Let the user
delete configsets she doesn't want any more, it's easy with the configsets api.
The principle of least surprise comes in to play here. Once a configset exists
in ZooKeeper, don't change it unless I tell you to. End of story.
I'd be OK if the guarantee is that the configset hasn't been changed since Solr
created it, in that case Solr can go ahead delete it with my blessing since
it'll be recreated just as it was if I recreate the collection. I.e. there is
no surprise in store for me. But otherwise -1 to both deleting it and
overwriting it.
This seems llike the tail wagging the dog. We have a situation where we want to
make it easy for the beginning user to get up and running. Solr does that by
copying the _default configset. This is good, it removes a barrier to entry.
Then users can spend quite a bit of time and effort modifying the configset to
satisfy their needs. We should not risk them losing those changes just to tidy
things up, which is all deleting configsets would really do. We should not risk
them losing those changes by overwriting an existing configset.
Other than having clean configs Znode, nobody has provided any compelling
reason that Solr controlling the lifecycle of a configset is valuable. There
are substantial risks do doing anything more than creating it if it doesn't
exist that we should avoid.
> _default configset overwrites a a configset if collection.configName isn't
> specified even if a confiset of the same name already exists.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-11624
> URL: https://issues.apache.org/jira/browse/SOLR-11624
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.2
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-11624.patch
>
>
> Looks like a problem that crept in when we changed the _default configset
> stuff.
> setup:
> upload a configset named "wiki"
> collections?action=CREATE&name=wiki&.....
> My custom configset "wiki" gets overwritten by _default and then used by the
> "wiki" collection.
> Assigning to myself only because it really needs to be fixed IMO and I don't
> want to lose track of it. Anyone else please feel free to take it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
