+1 to get rid of #1, #2, #3, #7. Maybe I'm mistaken but I thought "policy" was a part of the auto scaling framework?
Maybe the capability for autoAddReplicas should be considered an aspect of the auto scaling framework instead of a collection setting, and thus we could remove it here? I think the ability to modify collection.configName seems useful albeit rare to use in practice. Perhaps you want to try out a bunch of changes and want to easily roll back. You could create a config with those modifications, try it out, and if you don't like the results then point your config back to the original. Although In practice it may not always be possible to just switch configs since a reindex may be required. On Fri, Jun 15, 2018 at 7:22 AM Varun Thacker <[email protected]> wrote: > Today the Modify Collection supports the following properties to be > modified > > 1. maxShardsPerNode > 2. rule > 3. snitch > 4. policy > 5. collection.configName > 6. autoAddReplicas > 7. replicationFactor > > 1-4 seems something we should get rid of because we have the AutoScaling > Policy framework? > > 5> Can anyone point out the use-case for this? > > 6> autoAddReplicas can be changed as a clusterprop and modify-collection > API ? Hmm. Which one is supposed to win? > > 7> We need to allow a user to change replicationFactor. But how does this > help? We have nrtReplicas / pullReplicas / tlogReplicas so changing this > sounds just confusing? Or allow changing all replica types ? > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
