Shawn Heisey commented on SOLR-6733:

This comment is really long, and I've made a lot of edits before posting it.  
Hopefully it's all coherent!

You both make good points.  The overall intent would be to make things *easier* 
to configure, not harder.  Mostly by having all the configuration for the 
server centralized, with reasonable defaults for anything that's not mentioned. 
 Starting up with an entirely missing config would be a highly desired 
secondary goal.  Users would not be able to configure Jetty settings that are 
not explicitly handled by our code.  I think that's a plus for stability, but I 
acknowledge that flexibility does take a hit.  If embedded Jetty has a facility 
for reading and processing configs similar to the jetty.xml used by the full 
server, that could be an answer.

There will be plenty of opportunity for bikeshedding about the precise location 
and format (json, xml, properties, etc) of the new config file(s).  I have some 
ideas for a starting point, discussed below.

[~janhoy], your comments do bring up a notion that I've mentioned elsewhere: 
Always using ZK and eliminating the cloud mode distinction.  After some thought 
I decided to offer this solution instead, which i think has a lot of the same 
code simplification without the additional administrative overhead for users 
who don't want cloud:

In some cases the primary config file might only contain the TCP port, or it 
could be missing/empty.  Other typical settings for that config file would be 
things that may differ from node to node, and might include heap size, network 
interfaces to listen on, SSL config, and possibly a few more.  For cloud mode, 
ZK information (equivalents to zkRun and/or zkHost) would be required, and it 
might have hostname information for use when registering in live_nodes.  
Everything else (mostly handled by solr.in.sh, jetty config files, and solr.xml 
currently) would be loaded (if found) from a conf directory or a secondary 
config file that could exist in the filesystem or in ZK.  Leaning more towards 
a secondary config file, but if all properly named files in conf (or maybe 
conf.d) were loaded, it could be a way for a user to split their config up into 
logical pieces.  I'm torn on whether to support per-node secondary configs in 
ZK, but leaning away from it.

The startup could also look for an optional properties file and load that.  For 
backwards compatibility, environment variables could be checked and used when 
an explicit configuration doesn't exist.

For flexibility in what a user can do, I think that all possible settings 
should be honored whether they are in the primary config or the secondary, with 
the exception of things that only make sense in the primary config file, such 
as ZK settings and java options like heap size.  If somebody puts the same 
setting in different files (and it's not a setting where multiple mentions make 
sense), I think the one encountered first should take precedence, and a warning 
should be logged for any further occurrences.

Cores and their configs would be handled much as they are now, with 
improvements handled in other issues.

For SolrCloud, SSL config could be loaded from ZK instead of a config file.  
Mostly I imagine that being useful for users who create one certificate good 
for all nodes, but an idea that I'm leaning away from is per-node SSL configs 
in ZK.

For service installations, we can create /etc/solr/servicename, where the 
primary config for the service would live.  If the secondary config is not in 
ZK, it would also live there.

> Umbrella issue - Solr as a standalone application
> -------------------------------------------------
>                 Key: SOLR-6733
>                 URL: https://issues.apache.org/jira/browse/SOLR-6733
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Shawn Heisey
>            Priority: Major
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by 
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
>  * Create org.apache.solr.start.Main (and possibly other classes in the same 
> package), to be placed in solr-start.jar.  The Main class will contain the 
> main method that starts the embedded Jetty and Solr.  I do not know how to 
> adjust the build system to do this successfully.
>  * Handle central configurations in code -- TCP port, SSL, and things like 
> web.xml.
>  * For each of these steps, clean up any test fallout.
>  * Handle cloud-related configurations in code -- port, hostname, protocol, 
> etc.  Use the same information as the central configurations.
>  * Consider whether things like authentication need changes.
>  * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately 
> being applied only to master, not the stable branch.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to