murblanc commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-684077608
> NO You need to make a realistic proposal here IMO @noblepaul. And we need something that **already exists**. If placement plugins depend on some future rehaul of configuration in SolrCloud, we're pushing this way out because from past discussion there doesn't seem to be a consensus on how/if to remove `solr.xml` and how to support its features differently. The **absolute minimal** needs this PR has as far as configuration: - Define a classname to be loaded as the placement plugin factory - Define configuration passed to that plugin (int, long, string, boolean etc). Assign default values to these configs (for example maxReplicasOnNodeForGivenShard=1, maxCoresPerNode=9999) and allow the user to easily change them on its system - Allow picking the placement plugin AssignStrategy or the LEGACY or RULES one. And allow the end user to decide. Another need that I think makes life easier (esp. in testing) is being able to set this configuration to persist across Zookeeper wipes during tests. The solution I see is passing all these configs (everything I've added in `solr.xml` in the PR) as command line arguments (system properties) to Solr. The startup script would have to be distributed in the same way `solr.xml` would have to, and `solr.xml` can be put in Zookeeper, something impossible with the startup script. From the perspective of this PR I can switch to that (and rely on funky naming of system properties to know they need to be passed to the placementPlugin - remember these properties are defined by the plugin writer, not by us). Hard coding (in code) the type of `AssignStrategy` to use (then has to be `LEGACY` so `RULES` continue to work for collections that have them) and forcing the user to prime `clusterprops.json` to use anything else or to change the default config parameters of placement plugins (such as maxCoresPerNode) is going to make testing a nightmare, and we'll likely introduce automated priming mechanism that read their value from somewhere and push it to `clusterprops.json` on start up. I know I'll do that because I want to run SolrCloud with a fresh ZK very often so I delete the dir where ZK puts its stuff. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
